Each spring, I travel with a group of Rotarians to Nicaragua to help build healthcare clinics in remote areas. Before the trip, I always make an elaborate spreadsheet containing the medical information of each member of our team- allergies, immunizations, chronic conditions, medications, etc. -in case something happens and any of us need medical attention.
Although useful, the spreadsheet model obviously isn't the most efficient tool available for compiling and storing a medical record. Recently, I’ve been intrigued by personal health record (PHR) applications that are available online. The functional model of a PHR, defined by the HL7 organization, allows for the easy query of immunization records and access to medical information-subject to the proper authorization. The capability to access the health record of any member of the Nicaragua team from an Internet-capable device is certainly better than carrying around a spreadsheet file.
On a personal level, a recent trip to my local clinic convinced me of the benefits of maintaining a PHR. It took a receptionist ten minutes to type in my demographic information and medical history-even though I had been seen at that location less than two years ago. It turns out the facility had deployed a new health record system and had been unable to migrate any historic data. A simple URL link to my PHR with the proper authorization could have eliminated this problem.
These are two simple examples of how a PHR can increase efficiency; on a more pragmatic level, this technology has the potential to minimize the possibility of adverse drug interactions as well as prevent other common medical errors.
PHR’s are available today from many providers. Of particular note, IT industry heavyweights Google and Microsoft are attempting to carve out a share of this market. HIS and EMR vendors are also trying to stake a claim in this space; however, many of these PHR systems are "tethered" to a facility or vendor application.
For example, a hospital here in Dallas encourages its patients to use a PHR it provides. Unfortunately, the PHR is a vendor-based system that is, for all practical information transfer/access purposes, useless outside that institution.
Other than the obvious benefit to be gained from having a PHR, why are these applications of interest to medical imaging IT professionals? I’m fairly certain that it won’t be too long before patients begin arriving with a URL link to their prior imaging studies, which are stored in their PHR. And yes, there will undoubtedly be interoperability issues with a PACS.
Sunday, November 1, 2009
Healthcare Information Technology Management, Part 3 of 4
Part three of a four-part series on healthcare information technology. The information found in this article can be used as part of a preparation program for the American Board of Imaging Informatics (ABII) Imaging Informatics Professional certification program, which awards the Certified Imaging Informatics Professional (CIIP) designation.
The backbone of Healthcare Information Technology (HIT) is comprised of physical and logical networks, servers, databases, and archives. These elements comprise the engine the drives the HIT enterprise. The design and deployment of these HIT components requires a thorough knowledge of the interaction of one with the other, the capabilities of each, the standards affecting their implementation, and a planned upgrade path for when current technology is eclipsed by future innovation.
Structured Query Language (SQL)
SQL is used to communicate with a relational database, which is a structure in which the data consists of a collection of tables related to one another through common values.
This is fundamentally different than a hierarchical database; in a relational database there is no hierarchy among tables and any table can be accessed directly or potentially linked with any other table; there are no hard-coded, predefined paths among the data.
The two most prominent characteristics of a relational database are:
A row (also known as a record) represents a collection of information about a separate item (for example a patient).
Certain fields may be designated as keys, which mean that searches for specific values of that field will use indexing to speed them up.
A relationship is a logical link between two tables.
Where fields in two different tables take values from the same set, a join operation can be performed to select related records in the two tables by matching values in those fields.
Often, but not always, the fields will have the same name in both tables. For example, an "orders" table might contain (patient_id, image_code) pairs and a "patient" table might contain (patient_id, service_date and physician_code) so to review all of a patient's records you would join the patient_id fields of the two tables.
This can be extended to joining multiple tables on multiple fields. Because these relationships are only specified at retrieval time, relational databases are classed as a dynamic database management system.
Although most database systems use SQL, most of them also have their own additional proprietary extensions that are usually only used on their system.
Performance Indicators
Typically, a diagnostic imaging IT administrator acts as a PACS database manager—which includes the responsibilities of controlling read/write access, specifying report generation, and analyzing usage.
Common reports that can (and should) be generated as system and department performance generators in radiology include:
All relational database management systems (RDBMS) share the following characteristics:
The term "ORD" is sometimes used to describe external software products running over traditional DBMSs to provide similar features; these systems are more correctly referred to as object relational mapping systems.
Whereas RDBMS or SQL-DBMS products focused on the efficient management of data drawn from a limited set of data types (defined by the relevant language standards), an ORDBMS allows software developers to integrate their own types and the methods and apply to them into the DBMS.
Another advantage to the object-relational model is that the database can make use of the relationships between data to easily collect related records.
In an object database data is stored as objects.
Each object has a unique identifier. Data can be interpreted only using the methods specified by its class. The relationship between similar objects is preserved (inheritance) as are references between objects.
Two basic methods are used to store objects by different database vendors:
Dashboards are performance analysis tools that aggregate a collection of network metrics and present it to the healthcare IT administrator through a single interface.
For diagnostic imaging IT administrators, Paul Nagy, Ph.D., has developed and made freely available an open-source PACS dashboard, PacsPulse, for analyzing the performance of DICOM archiving traffic.
In addition to administrator dashboards, the concept has been extended by some vendors to the user work environment with dashboards available for radiologists and technologists in some PACS products.
The backbone of Healthcare Information Technology (HIT) is comprised of physical and logical networks, servers, databases, and archives. These elements comprise the engine the drives the HIT enterprise. The design and deployment of these HIT components requires a thorough knowledge of the interaction of one with the other, the capabilities of each, the standards affecting their implementation, and a planned upgrade path for when current technology is eclipsed by future innovation.
Structured Query Language (SQL)
SQL is used to communicate with a relational database, which is a structure in which the data consists of a collection of tables related to one another through common values.
This is fundamentally different than a hierarchical database; in a relational database there is no hierarchy among tables and any table can be accessed directly or potentially linked with any other table; there are no hard-coded, predefined paths among the data.
The two most prominent characteristics of a relational database are:
- Data is stored in tables; and
- There are relationships between tables.
A row (also known as a record) represents a collection of information about a separate item (for example a patient).
Certain fields may be designated as keys, which mean that searches for specific values of that field will use indexing to speed them up.
A relationship is a logical link between two tables.
Where fields in two different tables take values from the same set, a join operation can be performed to select related records in the two tables by matching values in those fields.
Often, but not always, the fields will have the same name in both tables. For example, an "orders" table might contain (patient_id, image_code) pairs and a "patient" table might contain (patient_id, service_date and physician_code) so to review all of a patient's records you would join the patient_id fields of the two tables.
This can be extended to joining multiple tables on multiple fields. Because these relationships are only specified at retrieval time, relational databases are classed as a dynamic database management system.
Although most database systems use SQL, most of them also have their own additional proprietary extensions that are usually only used on their system.
Performance Indicators
Typically, a diagnostic imaging IT administrator acts as a PACS database manager—which includes the responsibilities of controlling read/write access, specifying report generation, and analyzing usage.
Common reports that can (and should) be generated as system and department performance generators in radiology include:
- Utilization
- Uptime
- Capacity
- Exceptions
- Duplicates
- Lost studies
- Unread studies
All relational database management systems (RDBMS) share the following characteristics:
- Data model -- An RDBMS stores data in a database consisting of one or more tables of rows and columns. The rows correspond to a record (rule); the columns correspond to attributes (fields in the record). Each column has a data type (for example, date).
- Query language -- A view is a subset of a database that is the result of the evaluation of a query. The types of queries supported run the gamut from simple single-table queries to very complicated multi-table queries involving joins, nesting, set union/differences, and others.
- Computational model -- All processing is based on values in fields of records. Records do not have unique identifiers. The presentation of data as tables is independent of the way the data is physically stored on disk.
- There are no provisions for references from one record to another. Examining the result of a query is done under the control of a cursor that allows the user to step through the result set one record at a time. The same is true for updates.
The term "ORD" is sometimes used to describe external software products running over traditional DBMSs to provide similar features; these systems are more correctly referred to as object relational mapping systems.
Whereas RDBMS or SQL-DBMS products focused on the efficient management of data drawn from a limited set of data types (defined by the relevant language standards), an ORDBMS allows software developers to integrate their own types and the methods and apply to them into the DBMS.
Another advantage to the object-relational model is that the database can make use of the relationships between data to easily collect related records.
In an object database data is stored as objects.
Each object has a unique identifier. Data can be interpreted only using the methods specified by its class. The relationship between similar objects is preserved (inheritance) as are references between objects.
Two basic methods are used to store objects by different database vendors:
- Each object has a unique ID and is defined as a subclass of a base class, using inheritance to determine attributes.
- Virtual memory mapping is used for object storage and management. (a unique identifier for the location)
Dashboards are performance analysis tools that aggregate a collection of network metrics and present it to the healthcare IT administrator through a single interface.
For diagnostic imaging IT administrators, Paul Nagy, Ph.D., has developed and made freely available an open-source PACS dashboard, PacsPulse, for analyzing the performance of DICOM archiving traffic.
In addition to administrator dashboards, the concept has been extended by some vendors to the user work environment with dashboards available for radiologists and technologists in some PACS products.
Subscribe to:
Posts (Atom)