This is a post just to clarify the different terminologies used in Healthcare informatics and I feel annoyed when people use these terms intermittently as if they all mean the same.
EMR - Electronic Medical Record
The EMR is very medically focused and usually focuses on a particular medical domain for example orthopedics. EMR can be for a particular department in a hospital or a collection of patients medical information from all departments in a given hospital site. Rarely the scope of EMR extends outside a hospital even when it does it is usually for a organization which has multiple sites but never between two hospitals which belong to different organizations. This is a widely used term in N.America and Asia-Pacific and not commonly used in European countries.
EPR - Electronic Patient Record
This is a term which has its origins in the UK and essentially has the same definition as that of EMR. However the definition of EPR by NHS as “an electronic record of periodic health care of a single individual, provided mainly by one institution” makes EPR definition more patients centric. NHS has classified EPR into 6 levels
Level 1 - Patient Administration System and Departmental Systems
Level 2 - Integrated patient administration and departmental systems
Level 3 - Clinical activity support and noting
Level 4 - Clinical knowledge, decision support and integrated care pathways
Level 5 - Advanced clinical documentation and integration
Level 6 - Full multi-media EPR on line
EHR - Electronic Health Record
Electronic Health Record (EHR) is described as the concept of electronic longitudinal collection of patient’s health and health care – from cradle to grave. It combines information from different care settings held in different systems and in some instances aggregates the data and shows them as a single record.
The Committee for European Normalization provides the following definition for EHR:
“A repository of information in a computer readable format regarding the health of a subject of care “
The Australian National EHR Taskforce, defined EHR as
“an electronic longitudinal collection of personal health information based on an individual or family and entered or accepted by healthcare professionals .It can be distributed over a number of sites or aggregated at a particular source including a hand held device. The information is organised primarily to support continuing, efficient and quality healthcare.”
Monday, 26 February 2007
Thursday, 15 February 2007
20 Minute HL7V2.x Primer
HL7 V2 Philosophy
The philosophy of HL7V2.x is based on the assumption that a real event that occurs in a healthcare setting creates data that needs to be exchanged between different systems of that setting. This is essentially to eliminate duplication of data collection from the patients and to automate administrative process saving time and money.
The real world events e.g. patient admitted or Lab orders raised are represented by trigger events and messages are specified for each trigger event. The structure of an HL7v2.x message is shown in Figure 1 below
The philosophy of HL7V2.x is based on the assumption that a real event that occurs in a healthcare setting creates data that needs to be exchanged between different systems of that setting. This is essentially to eliminate duplication of data collection from the patients and to automate administrative process saving time and money.
The real world events e.g. patient admitted or Lab orders raised are represented by trigger events and messages are specified for each trigger event. The structure of an HL7v2.x message is shown in Figure 1 below
Figure 1: Version 2 Message Structure
Segments - Version 2.X messages are designed around message segments indicated by a three letter segment id e.g. PID – Patient Identification; ORC- Common Order etc. Each message is composed of a group of segments in a defined sequence. Segments of message many be mandatory or optional and may repeat .A segment is a delimited line of data that contains data relevant to one specific use in the message. For example, patient identification information is in PID segment while patient allergies are defined in AL1 segment. Groups can be thought of as simply a collection of segments or other groups.
The HL7V2.x standard specification defines the standards segments. However the messages can also contain segments that are not part of the standard. These segments are locally-defined segments, called “Z-Segments” as their Segment ID code begins with a “Z”. These are allowed to add flexibility to the standard and usually appear at the end of the relevant segment group.
Each segment is a logical grouping of data fields. then composed of data fields. Each data field can have one or more components and each component may have sub-components.
Segments - Version 2.X messages are designed around message segments indicated by a three letter segment id e.g. PID – Patient Identification; ORC- Common Order etc. Each message is composed of a group of segments in a defined sequence. Segments of message many be mandatory or optional and may repeat .A segment is a delimited line of data that contains data relevant to one specific use in the message. For example, patient identification information is in PID segment while patient allergies are defined in AL1 segment. Groups can be thought of as simply a collection of segments or other groups.
The HL7V2.x standard specification defines the standards segments. However the messages can also contain segments that are not part of the standard. These segments are locally-defined segments, called “Z-Segments” as their Segment ID code begins with a “Z”. These are allowed to add flexibility to the standard and usually appear at the end of the relevant segment group.
Each segment is a logical grouping of data fields. then composed of data fields. Each data field can have one or more components and each component may have sub-components.
HL7 V2.x History
HL7 1.0 originated in 1987 as an open standard for vendors for interfacing different clinical systems within an organization. It was defined in a period of six months with initial set of Orders and ADT messages. They were not widely implemented but laid a foundation for defining standard healthcare interfaces. HL7 v2.0 which was demonstrated at 1989 HIMSS convention introduced the concept of triggers, added additional detail to the Message header, and expanded the set of messages to include billing. HL7V2.0 was also not widely implemented. Figure 2 below shows a timeline of HL7 Version 2 releases.
HL7 1.0 originated in 1987 as an open standard for vendors for interfacing different clinical systems within an organization. It was defined in a period of six months with initial set of Orders and ADT messages. They were not widely implemented but laid a foundation for defining standard healthcare interfaces. HL7 v2.0 which was demonstrated at 1989 HIMSS convention introduced the concept of triggers, added additional detail to the Message header, and expanded the set of messages to include billing. HL7V2.0 was also not widely implemented. Figure 2 below shows a timeline of HL7 Version 2 releases.
Figure 2: Version 2 Timeline
HL7 Version 2.1 - HL7 Version 2.1 is the first widely used standard after its publication in March1990.HL7 2.1 is still in use today by some clinical systems.
HL7 Version 2.2 - HL7 Version 2.2 is primarily centered around cleaning up and clarifying version 2.1 specifications The notable changes to version 2.2 among others is that Segments were added to existing events for e.g. Merge Segment was added to the Transfer events (A06 & A07); Next of Kin Segment was added to the Patient Query (A19) event. Some additional fields were added to segments for e.g. additional fields to PID segment to handle newborn baby information and Next of Kin was made more generic to handle any person associated with the patient. New messages to handle Pharmacy, Diet and supply orders were added. Apart from adding new data types the HL7 acknowledgment paradigm has been extended to distinguish both accept and application acknowledgments, as well the conditions under which each is required.
HL7 Version 2.3 - Version 2.3 offers new data types, especially the 'x'-tended versions of PN, CN, etc. Enhanced query functionality and clear definitions of tables for e.g. differentiating ID/IS data types. In Financial Management Additional messages were added and message constructs were extended to allow greater specificity in the intent of the message, and to report additional information.
HL7 Version 2.2 - HL7 Version 2.2 is primarily centered around cleaning up and clarifying version 2.1 specifications The notable changes to version 2.2 among others is that Segments were added to existing events for e.g. Merge Segment was added to the Transfer events (A06 & A07); Next of Kin Segment was added to the Patient Query (A19) event. Some additional fields were added to segments for e.g. additional fields to PID segment to handle newborn baby information and Next of Kin was made more generic to handle any person associated with the patient. New messages to handle Pharmacy, Diet and supply orders were added. Apart from adding new data types the HL7 acknowledgment paradigm has been extended to distinguish both accept and application acknowledgments, as well the conditions under which each is required.
HL7 Version 2.3 - Version 2.3 offers new data types, especially the 'x'-tended versions of PN, CN, etc. Enhanced query functionality and clear definitions of tables for e.g. differentiating ID/IS data types. In Financial Management Additional messages were added and message constructs were extended to allow greater specificity in the intent of the message, and to report additional information.
HL7 Version 2.3.1 - HL7 V.2.3.1 includes an updated TQ (timing/quantity) datatype to manage order occurrences, updates to the OBR segments and ORU message to facilitate public health surveillance reporting, updates to tables, segments and data types to accommodate international paradigms for reporting names and pharmacy orders, and the addition of a new field to the ORC segment to satisfy the HCFA Medical Necessity requirements for outpatient services, and an update to the FT segment to satisfy federal requirements for Level 2 Modifiers.
HL7 Version 2.4 – Version 2.4 is approved as an ANSI standard in October 2000. HL7 v.24 introduces Conformance Query profiles, and adds messages for laboratory automation, application management and personnel management. Additionally, a new event, specific to OPPS and APC requirements was added. This event, Transmit Ambulatory Payment, includes two new segments, the Grouping/Reimbursement Visit Segment and the Grouping Reimbursement Procedure Segment.
HL7 V2.x Message Construction
Message Encoding Rules: Version 2.x messages have some defined special characters that delineate data fields which make up the message. These special characters are the segment terminator, the field separator, the component separator, the sub-component separator, and the repetition separator. Table 1 below shows the definition of these separators
Table 1: Version 2 Separators
HL7 V2.x Message Construction
Message Encoding Rules: Version 2.x messages have some defined special characters that delineate data fields which make up the message. These special characters are the segment terminator, the field separator, the component separator, the sub-component separator, and the repetition separator. Table 1 below shows the definition of these separators
Table 1: Version 2 Separators
The interface that implements version 2.x messages will use escape sequences for e.g. \F\- Field Separator to signify that reserved characters (delimiter or separator characters) is present in the value
Message Construction Rules: A Version 2.x message consists of segments. Message segments are constructed in the order defined below
1. The first three characters in the message segment that will be inserted into the message is the segment ID code, e.g. - PID – Patient Identification Details.
2. Each segments consists of different fields and each of those data fields that make up a segments are inserted into the segment in sequence:
2.1 A field separator ¦XYZ¦ is placed at the beginning and the end of the field. If there is no value present in the field then no other characters are required and a ¦¦ is used.
2.2 If the value is present but equivalent to null, two consecutive quotation marks are placed in the field ¦""¦.
2.3 If a field is defined to have components (combination of meaningful data fields), the following rules apply:
- Components are separated by the component separator.
- Components that are present but null are represented by two consecutive quotation marks
- Components with no value require a component delimiter but do not require characters in the component. For example: ¦ABC^^DEF¦
- Components at the end of a data field with no value do not have to be represented by a component delimiter. For example: ¦ABC^DEF^^¦ = ¦ABC^DEF¦
- When a component is itself a data type that contains components, its delimiters are demoted by one. For example, the component delimiters for the composite field ¦ABC^DEF¦ are demoted by one to ¦JKL^ABC&DEF¦
2.4 If component has sub-components, the following rules apply:
- Sub-components are separated by the sub-component separator.
- Sub-components that are present but null are represented by two consecutive quotation marks.
- Sub-components that are not present require place holder separator but no characters in the sub-component.
- Sub-components at the end of a data field with no value do not have to be represented by a sub-component delimiter.
2.5 If the field definition permits repetition, the repetition separator is used only if more than one occurrence is transmitted. The repetition separator is placed between occurrences.
2.6 End each segment with an ASCII Carriage Return character - ASCII(13), HEX(0D).
3. Steps 1 and 2 are repeated until all segments have been generated.
4. The receiving system will ignore segments, fields, components, and extra repetitions that are present but not expected. The receiving system will treat segments that are expected but not present as consisting entirely of fields that are “not present”, and it will treat fields and components that are expected but not included in a segment as “not present”.
Data Types: Data types define the structure of the fields. Data type specification is an important tool for simplifying the complexity of the HL7 standard, and is critical for understanding the data contents of an HL7 field.
Version 2 supports the following data types
- Primitive – consisting of one component e.g. ST(String)
- Simple – multiple components, no ‘type’ code e.g. CE (Coded Element)
- Complex – multiple components with a ‘type’ code e.g. XAD(Extended Address)
The application of data types to the fields can be gauged by the following examples.
The format of CE as per version 2 specification is
CE :< identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>
11289-6 is the identifier; Body Temperature is the text and LN (LONIC) is the name of the coding system.
The format of XAD as per version 2 specification is
XAD : <street address (ST)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or province (ST)> ^ <zip or postal code(ST)> ^ <country (ID)> ^ < address type (ID)> ^ <other geographic designation (ST)>^ <county/parish code
(IS)> ^ <census tract (IS)>
e.g.: ¦23 Sussex Place ^Flat 3 ^ Slough ^ Berkshire^SL11NH^UK^P^^BERK^¦
23 Sussex Place corresponds to street address ; Flat 3 for other designation; Slough for city; Berkshire for state;SL11NH for postcode; UK for country and P which stands for permanent.
HL7V2.x Message Anatomy
Imagine the following scenario
- Patient Andy Smith Carol was admitted on July 22, 2006 at 11:23 a.m. by Doctor John Carol (#C145678) for an orthopedic procedure (ORT).
- He has been assigned to room 202, bed 10 on nursing unit 1000.
- The Patient Lives at 23, Sussex Place, Slough, Berkshire, SL11NH and was born on December 23rd 1961.
- The hospital the Mary Green Maternity – MGM has PAS System - ADT1 and a laboratory system PATHLAB.
The admission of the patient corresponds to a trigger for Admit patients and an event A01 is intended for admitted patients. This will be sent from PAS system to Lab system in real time as soon as the admission takes place. According to HL7 V2.3.1 message specifications a portion of message structure of A01 shown in Table 2
Table 2: A01 Message Structure
Download the complete A01 HL7 V2.3 message specifications from HL7 website (http://www.hl7.org/)
The most important fields in the message segment (MSH) header are shown below in Table 3.
Table 3: Relevant MSH Fields
The message segment MSH shown below sent in the message based on the scenario above shows what has been sent in the following scenario with the data items from the PAS database populating these fields.
The other important message segment PID in A01 whose important fields are shown in Table 4. The complete list of fields is available from v2.3.1 Message pack on HL7 Website.
Table4: Relevant PID fields
The message segment PID shown below sent in the message based on the scenario above shows what has been sent in the following scenario with the data items from the PAS database populating these fields.
Messaging Communication: The most commonly used mechanism for sending HL7 Version 2.x messages is Lower Layer Transport protocol (LLP). The messages are sent over TCP/IP over the network.
The protocol is very simple to implement using the implementation setting sockets. The protocol requires that that each message should be preceded with the character 0x0B (11) and followed with the characters 0x1C (28) and 0x0D (13). This is required for communications code to be able to recognize the start and the end of each message
Finally each segment is terminated by a 0x0D (13) character. This is mandated by the standard, but often HL7 log data can be received via ftp or email where the segment separators have been transformed into 0x0A characters, etc
Current Status of HL7V2
Some countries such as Germany have legislation that stipulates the use of V2.X, and V2.4 which is a ANSI standard from 2004 is now being proposed as an ISO standard, making it a truly international standard though it have been developed for American market.
The Version 2.x standards are widely used in different countries in the world, in particular in acute healthcare settings and in some countries even in primary care. The HL7 versions 2.1 to 2.5 which have been published are in wide use and the work is underway on V2.6, which is expected to be published late 2005/early 2006.
Version 2.5 – HL7 Version 2.5 is the last published standard in the HL7 Version 2.x series. Version 2.5 contains new messages and updates to HL7 Version 2.4. Version 2.5 is supposed to be broader in scope that Canadian Health Information Technology Trade Association (CHITTA) have issued a position paper to Canada Health Infoway urging the agency to reconsider its support of Health Level 7 (HL7) Version 3 in view of the supposed unavailability of Version 3 normalised specifications (Ref: Section xxx) and asked it to endorse HL7V2.5 which provides greater interoperability. HL7 Version 2.5 introduced a number of new events, segments and messages and expanded the Control section. Version 2.5 is more consistent and supports more functionality than any of the previous versions. The significant modifications to version 2.5 are
- Better and clearer documentation of the data types
- A definition of a message profile methodology
- Better support for Radiology/Imaging by means of a new segment and a new order message
- Support for orders related to blood products
- New update message for diagnosis/procedures
- New specification of claims and reimbursement messages
Version 2.6 - HL7 Version 2.6 completed the first ballot cycle in September 2004 and is nearing completion and will be released in 2006. V2.6 will include enhancements made to allow the communication of Electronic Health Record (EHR) information which is sighted as one of the biggest deficiency of version2.x. Version 2.6 is an upgrade to HL7 Version 2.5 and it includes new segments, fields, components and subcomponents necessary to apply either a documented regulatory requirement or a harmonization requirement with HL7 Version 2 material created by other committees. The main changes to version 2.6 from version 2.5 are
- Addition of general new segment -UAC "User Authentication Credential"
- Better management of access to sensitive patient information by adding Access Restrictions (ARV) segment.
- New message type to support the US National Animal Health Laboratory Network (NAHLN)
- Deprecation of data types such as CNN,LA1, LA2 and NDL data types
- Addition of components to the XAD and XTM data types.
- "TS" Timestamp data type is being replaced by the DTM "Date/Time" data type.
- CE "Coded Element" data type is being replaced by either the CNE "Coded with No Exceptions" or the CWE "Coded with Exceptions" data types
- Code tables defined by external standards organizations will not be considered as HL7 tables but an HL7 number will be assigned.
- Many new fields have been added to the segments in the Financial Management
- “Observation Reporting” chapter has added support for referral and shared care
- Personnel Management chapter contains new attributes to the STF and ROL segments.
- New chapter Materials Management with messages for communicating various events related to the appointment scheduling for services and resources
XML encoding :The German HL7 group defined a comprehensive database of the HL7 standard to allow consistency checks of items and to support the application of the standard by the user when they realized that the different chapters in the published standard have been developed by different groups and there are no distinct rules or guidelines for the development of various parts of the standard.
The database is a Microsoft Access database and contains the official definitions for events, messages, segments, fields, data types, components, tables and values. An XML representation of version 2.x standard is algorithmically derived directly from this database. The algorithm consists of SQL queries to extract tables which are then exported to ASCII delimited files. Perl scripts are applied to these ASCII files to generate XML DTD’s.
Two sets of DTD’s have been provided;
A single DTD (hl7_v231.dtd) that contains all HL7V2.3.1 definitions. This file is broken up into four separate DTD definitions – Message.dtd; segments.dtd; fields.dtd datatypes.dtd.
One DTD for each message structure. Each imports the same datatype DTD referenced by hl7_v231.dtd, but is otherwise self contained with all message, segment and field declarations needed for the message structure.
The XML representation represents HL7 message structures as XML elements. Message structures contain segments, also represented as XML elements. Segments contain fields, again representedas XML elements. A field's data type is stored as a fixed attribute in the field's attribute list, while a field'scontent model contains the data type components. Other fixed attributes are used to expand abbreviations and indicate HL7 Table value restrictions
A simple version 2.x representation is shown below
The representation of the above message using XML encoding rules is shown below.
Tuesday, 13 February 2007
AJAX and Healthcare IT
One of the most important factors in driving users towards higher use of clinical systems is providing an effective user interface. Specifically for web based clinical applications it is quite a challenge to provide an effective user interface. AJAX (Asynchronous JavaScript and Extensible Markup Language) is emerging as an effective solution in providing such a interface
For starters Ajax lets web pages feel active and interactive in real time by exchanging small packets of data behind the scenes so that the entire web page doesn't have to be reloaded each time the user requests new information. Ajax makes web-based applications look and act like desktop applications. Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:
• standards-based presentation using XHTML and CSS;
• dynamic display and interaction using the Document Object Model;
• data interchange and manipulation using XML and XSLT;
• asynchronous data retrieval using XMLHttpRequest;
• and JavaScript binding everything together.
For a more detailed understanding of AJAX Refer to this article http://adaptivepath.com/publications/essays/archives/000385.php
In healthcare IT AJAX can play a big role in simplifying User Interface workflows for end users. For example typically in existing applications scheduling of clinicians in an enterprise requires the clinician details to be searched before slots are associated for performing activities like procedures in different departments. AJAX allows auto-completion of data and it could aid in typing in clinicians names, procedure names, department names instead of remembering the codes associated with it. No popup listing and scanning down a list of values or searching is required.
It is typical while working in departments like Mental and Psychiatric departments large amounts of clinical data needs to be captured in one single form. It is often quite frustrating in web based applications after filling in the data accidental clicking on the wrong icon or page link causes complete loss of data. We can using AJAX we can to persist the values of form fields into the HTTPSession step by step, just incase someone clicks off their page by mistake or loses their work.
AJAX can also be used to navigate huge procedures tree, while retrieving the required element. This enabled us to deliver a much better user interface and lessens the data entry time.
One of the most exciting uses of AJAX can be for developing a UI for quick browsing and selecting of clinical codes. SNOMED-CT is emerging worldwide as the most dominant clinical coding standards. At the moment, most SNOMED-CT browsing is done using a free (but not open source) Visual Basic GUI application called CLUE (see http://www.clininfo.co.uk/clue5/index.htm). Ask any clinician or any organization where CLUE is used they can tell the issues associated with it. AJAX can be used to provide a Web-based SNOMED-CT browser/search facility to provide good interactivity in letting the clinicians browse and choose the correct SNOMED concept. The provision of SNOMED-CT look-up facility using AJAX can be used for both open source and closed source clinical applications. An AJAX based SNOMED browser will enable distribution of codes through a central service or access clinical codes locally. This will enable updating of clinical codes in local systems automatically either by client side polling or by user invoked requests.
One of the major hindrances of a nation wide EHR is the inability to provide an affordable application with a user interface relevant to organizations of different size ranging from a Family Physician office to a Big General Hospital. A web based solution centrally hosted solution is the oft quoted answer for this but it is a known fact that web based solution negates the rich experience of a local client apart from not catering to an individual organization needs. AJAX makes these web based user interfaces much more interactive without requiring the typical submit/post/redraw round-trip of an HTML interface. AJAX uses the “The Web as Platform" paradigm and allows Ajax desktops or personalized UI suiting to the organization.
For starters Ajax lets web pages feel active and interactive in real time by exchanging small packets of data behind the scenes so that the entire web page doesn't have to be reloaded each time the user requests new information. Ajax makes web-based applications look and act like desktop applications. Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:
• standards-based presentation using XHTML and CSS;
• dynamic display and interaction using the Document Object Model;
• data interchange and manipulation using XML and XSLT;
• asynchronous data retrieval using XMLHttpRequest;
• and JavaScript binding everything together.
For a more detailed understanding of AJAX Refer to this article http://adaptivepath.com/publications/essays/archives/000385.php
In healthcare IT AJAX can play a big role in simplifying User Interface workflows for end users. For example typically in existing applications scheduling of clinicians in an enterprise requires the clinician details to be searched before slots are associated for performing activities like procedures in different departments. AJAX allows auto-completion of data and it could aid in typing in clinicians names, procedure names, department names instead of remembering the codes associated with it. No popup listing and scanning down a list of values or searching is required.
It is typical while working in departments like Mental and Psychiatric departments large amounts of clinical data needs to be captured in one single form. It is often quite frustrating in web based applications after filling in the data accidental clicking on the wrong icon or page link causes complete loss of data. We can using AJAX we can to persist the values of form fields into the HTTPSession step by step, just incase someone clicks off their page by mistake or loses their work.
AJAX can also be used to navigate huge procedures tree, while retrieving the required element. This enabled us to deliver a much better user interface and lessens the data entry time.
One of the most exciting uses of AJAX can be for developing a UI for quick browsing and selecting of clinical codes. SNOMED-CT is emerging worldwide as the most dominant clinical coding standards. At the moment, most SNOMED-CT browsing is done using a free (but not open source) Visual Basic GUI application called CLUE (see http://www.clininfo.co.uk/clue5/index.htm). Ask any clinician or any organization where CLUE is used they can tell the issues associated with it. AJAX can be used to provide a Web-based SNOMED-CT browser/search facility to provide good interactivity in letting the clinicians browse and choose the correct SNOMED concept. The provision of SNOMED-CT look-up facility using AJAX can be used for both open source and closed source clinical applications. An AJAX based SNOMED browser will enable distribution of codes through a central service or access clinical codes locally. This will enable updating of clinical codes in local systems automatically either by client side polling or by user invoked requests.
One of the major hindrances of a nation wide EHR is the inability to provide an affordable application with a user interface relevant to organizations of different size ranging from a Family Physician office to a Big General Hospital. A web based solution centrally hosted solution is the oft quoted answer for this but it is a known fact that web based solution negates the rich experience of a local client apart from not catering to an individual organization needs. AJAX makes these web based user interfaces much more interactive without requiring the typical submit/post/redraw round-trip of an HTML interface. AJAX uses the “The Web as Platform" paradigm and allows Ajax desktops or personalized UI suiting to the organization.
Wednesday, 7 February 2007
Informational Governance and EHR
Most of the national EHR implementations seem to be plauged with issues concering the security of the data. Though it has been realised long back that Privacy and security are of utmost importance in the design of the EHR infrastructure enough attention has not been given by the policy makers involved in the deployment of EHR in their respective countries towards this.
A Canadian poll result indicated that the two most biggest concerns of the patients in the deployment of EHR in their country are
- Confidentiality and Privacy - 54%
- Safety of information - 31%
The key IG principles that need to be considered for building EHR are
- Restriction of access of the EHR to clinicians who currently have a duty of care for the individual concerned-The biggest issue with this principle is the decision to consider whetehr we restrict access to individual clinicans or group of cincians who are responsible for the care of the patient. It is a known fact that clinicans rarely work in silos expecially in acute settings.
- It should be possible to assign personally requested special levels of confidentiality to specific health information held in the EHR- Most people assume a simple Role Based Accesss is the solution for this but the key to this principle is associating multiple business activites with a role and linking thse activities to users of that role.
- EHR availability should be restricted within the organizational boundary within which it is created, except with patient consent -The issue with consent is the issues associated with explicit and implict consent and should the clinicans be able to override the dissent in case of emergenices.
- Operational staff (administrative and IT) should only have access to the minimum information required to perform their task-It is a well known fact more than outsiders it is insiders and more prominently operational staff who leak clinical data. But the issue is what level of data is minimal data ; how will the issues related to data inconsistency be resolved without operational staff looking at the data.
- All EHRs should have an automated and tamper-proof audit trail including a logof access which should be available to the patient.-Tamper proof audit trial should not be just a simple database log but much more secure than that for example we can considerr triggering alerts to responsible clinicans when patients sensitive data is viewed which shoud help mitigate this problem to a extent.
- The physical machinery storing the EHR should be protected -Proper Resilience and Disaster Recovery controls are key to this; a crucial factor is the amount of time taken to failover which is not a factor for secuirty but key factor for patient safety.
Tuesday, 6 February 2007
Candian Infoway and Myths
Ref: http://www.itbusiness.ca/it/client/en/Home/News.asp?id=40138&bSearch=True)
Canadian Infoway which aims to have a nationwide EHR by 2009 has recommended vendors to use version 3.0 in its blueprint. In 2006 The Association of health technologies industry (AITS) and the Canadian Health Information Technology Trade Association (CHITTA) have issued a position paper to Canada Health Infoway urging the agency to reconsider its support of Health Level 7 (HL7) Version 3. The paper calls instead for Infoway to endorse HL7v2.5, which the associations say provides greater interoperability.
This is old news but the reason why i felt compelled to blog on this issue is the following presentation which is a more recent one on the infoway site
http://sl.infoway-inforoute.ca/downloads/HL7_CAN_Address_to_CRIM-AITS_October_2006_Final.pdf
Slide- 44
Myth #1• Interoperability on a large scale is possible with HL7 V2
Reality
• There is no common, pan-Canadian V2 standard
• No organization in North America is using V2.5
• The optionality in V2 inhibits (and in many cases, practically prevents)interoperability• V2 messages are designed for point-to-point systems integration, and donot easily support reuse and replication
• We need computable semantic interoperability in order to be successful withour agenda. HL7 V3 has the information model, robust data types,terminology bindings and a robust modeling methodology which support ourneeds …. and V2 does not
My Comment :Well i dont understand the concept of pan-canadian understandard. One of the biggest advantage of HL7V2.x is getting different versions of HL7V2.x interoperate with one another. The rules for compatibility between different versions (e.g. V2.3.1, V2.4 and V2.5) have been documented in the specifications. These rules describe the transmission and receipt of messages and converting their contents to data values with full backward compatibility between all 2.x versions of HL7.
So is it not better to use V2.x and force and constrain systems vendors and organisations on issues of optionality and using standard codesets rather than using V3.0
The next point is a bit contentious where it is said there is no "No organization in North America is using V2.5" by that standards then there are no organisations in N.America which use V3.0. Apart from this Biosurveillance Technical Committee in US which submitted its selected standards Healthcare Information Technology Standards Panel did endorse HL7V2.5 as one of the for use in construction of the Interoperability.
V2 messages are designed for point-to-point systems integration,this is a statement which is highly debatable considering the fact that several organisations which adopted middleware based integartion-EAI or SOA use V2.x.
The statement that "HL7 V3 has the information model, robust data types,terminology bindings and a robust modeling methodology which support ourneeds" is right to some extent but given the problems associated with the stability of RIM and the number of revisions it went through and the known problems of V3 messages with SNOMED-CT dimmens the context and relevance of the statement.
SLIDE-45
Myth #2
• Vendors will not commit to pan-Canadian standards and HL7 V3
Reality
• Not all vendors will or can
• Vendors are responding to the growing market demand being advanced byInfoway ... We need to grow that market demand!– Vendors also complying with standards when these are specified in RFPs, egCeRx for PEI and NL– There are V3 implementations in progress: IBM, Eclipse open source, Emergis,DeltaWare, etc
• Vendor community representatives are committed to pan-Canadianstandards so they only have to implement once and conformance test once• It’s largely not a V2 versus V3 issue. Often the challenge is XML enablementof the application, new functionality, new data requirements, newterminologies, not the V3 message syntax
My Comment:The realities quoted in it does indicate that V3 implementaions are in progress and the end result is not known. The slide also says "XML enablementof the application" is the issue not a v2 versus v3 issue ; well we do have V2.x XML encoding for which ready made adpaters are available from several vendors.
SLIDE-48
Myth #5
• All existing local standards must be replaced with pan-Canadian standards
Reality
• Example 1 – All existing HL7 messages do not need to be replaced with HL7v3 messages– V2 and V3 can co-exist, V3 can be mapped to V2, and V3 compliance can beachieved (with V2 components) with the use of brokers
• Example 2 - PoS systems are not required to update internal HL7 v2.xmessages to use the pan-Canadian standards– Pan-Canadian standards are not focused at the Departmental level but are forinteroperability with the pan-Canadian EHR or jurisdictional repositories
• We are requiring that new HL7 messages to communicate with the HIAL beimplemented in V3, not v2.x.
• Implementation of a pan-Canadian standard is most feasible when a net-newsystem is being installed, or an existing system is being enhanced.
My Comment:Well V2 and V3 co-existing is a reality and its happening as can be seen in the English NHS project where intra organisation integartion is done using V2.x and messages to national EHR is done using V3.0. But the statement that V3 compliance can be acheived with v2 components and use if brokers is really far fetched statement. The mapping or translation of v2-v3 is not defined properly nor any detailed documentation on the mapping is available. It is also a know fact that HL7 v3 is much more detailed than HL7 v2 and the trigger events in V2 and V3 are sufficiently different apart from the bussiness process which triggers those messages.
Iam not saying that HL7V3.0 is better compared to V2,0 but when making a statement to vendors to instill confidence in them atleast make a realistic and fact filled statement not a statement which hangs on a set of incorrect "Realities" .
Canadian Infoway which aims to have a nationwide EHR by 2009 has recommended vendors to use version 3.0 in its blueprint. In 2006 The Association of health technologies industry (AITS) and the Canadian Health Information Technology Trade Association (CHITTA) have issued a position paper to Canada Health Infoway urging the agency to reconsider its support of Health Level 7 (HL7) Version 3. The paper calls instead for Infoway to endorse HL7v2.5, which the associations say provides greater interoperability.
This is old news but the reason why i felt compelled to blog on this issue is the following presentation which is a more recent one on the infoway site
http://sl.infoway-inforoute.ca/downloads/HL7_CAN_Address_to_CRIM-AITS_October_2006_Final.pdf
Slide- 44
Myth #1• Interoperability on a large scale is possible with HL7 V2
Reality
• There is no common, pan-Canadian V2 standard
• No organization in North America is using V2.5
• The optionality in V2 inhibits (and in many cases, practically prevents)interoperability• V2 messages are designed for point-to-point systems integration, and donot easily support reuse and replication
• We need computable semantic interoperability in order to be successful withour agenda. HL7 V3 has the information model, robust data types,terminology bindings and a robust modeling methodology which support ourneeds …. and V2 does not
My Comment :Well i dont understand the concept of pan-canadian understandard. One of the biggest advantage of HL7V2.x is getting different versions of HL7V2.x interoperate with one another. The rules for compatibility between different versions (e.g. V2.3.1, V2.4 and V2.5) have been documented in the specifications. These rules describe the transmission and receipt of messages and converting their contents to data values with full backward compatibility between all 2.x versions of HL7.
So is it not better to use V2.x and force and constrain systems vendors and organisations on issues of optionality and using standard codesets rather than using V3.0
The next point is a bit contentious where it is said there is no "No organization in North America is using V2.5" by that standards then there are no organisations in N.America which use V3.0. Apart from this Biosurveillance Technical Committee in US which submitted its selected standards Healthcare Information Technology Standards Panel did endorse HL7V2.5 as one of the for use in construction of the Interoperability.
V2 messages are designed for point-to-point systems integration,this is a statement which is highly debatable considering the fact that several organisations which adopted middleware based integartion-EAI or SOA use V2.x.
The statement that "HL7 V3 has the information model, robust data types,terminology bindings and a robust modeling methodology which support ourneeds" is right to some extent but given the problems associated with the stability of RIM and the number of revisions it went through and the known problems of V3 messages with SNOMED-CT dimmens the context and relevance of the statement.
SLIDE-45
Myth #2
• Vendors will not commit to pan-Canadian standards and HL7 V3
Reality
• Not all vendors will or can
• Vendors are responding to the growing market demand being advanced byInfoway ... We need to grow that market demand!– Vendors also complying with standards when these are specified in RFPs, egCeRx for PEI and NL– There are V3 implementations in progress: IBM, Eclipse open source, Emergis,DeltaWare, etc
• Vendor community representatives are committed to pan-Canadianstandards so they only have to implement once and conformance test once• It’s largely not a V2 versus V3 issue. Often the challenge is XML enablementof the application, new functionality, new data requirements, newterminologies, not the V3 message syntax
My Comment:The realities quoted in it does indicate that V3 implementaions are in progress and the end result is not known. The slide also says "XML enablementof the application" is the issue not a v2 versus v3 issue ; well we do have V2.x XML encoding for which ready made adpaters are available from several vendors.
SLIDE-48
Myth #5
• All existing local standards must be replaced with pan-Canadian standards
Reality
• Example 1 – All existing HL7 messages do not need to be replaced with HL7v3 messages– V2 and V3 can co-exist, V3 can be mapped to V2, and V3 compliance can beachieved (with V2 components) with the use of brokers
• Example 2 - PoS systems are not required to update internal HL7 v2.xmessages to use the pan-Canadian standards– Pan-Canadian standards are not focused at the Departmental level but are forinteroperability with the pan-Canadian EHR or jurisdictional repositories
• We are requiring that new HL7 messages to communicate with the HIAL beimplemented in V3, not v2.x.
• Implementation of a pan-Canadian standard is most feasible when a net-newsystem is being installed, or an existing system is being enhanced.
My Comment:Well V2 and V3 co-existing is a reality and its happening as can be seen in the English NHS project where intra organisation integartion is done using V2.x and messages to national EHR is done using V3.0. But the statement that V3 compliance can be acheived with v2 components and use if brokers is really far fetched statement. The mapping or translation of v2-v3 is not defined properly nor any detailed documentation on the mapping is available. It is also a know fact that HL7 v3 is much more detailed than HL7 v2 and the trigger events in V2 and V3 are sufficiently different apart from the bussiness process which triggers those messages.
Iam not saying that HL7V3.0 is better compared to V2,0 but when making a statement to vendors to instill confidence in them atleast make a realistic and fact filled statement not a statement which hangs on a set of incorrect "Realities" .
Subscribe to:
Posts (Atom)