Implementation FAQ:Framework Issues

This page contains questions and recommendations related to implementations of v3 in the context of a "Framework". A Framework is defined to be the set of message and infrastructural specifications and business rules as defined by an inter-organizational body; either at a regional or national level. Examples include the English NPfIT Program, the Dutch AORTA National Infrastructure, or specifications applicable within a U.S. HMO. The Framework is mostly published as a set of implementation guides. Implementation Guides represent the HL7 standard profiled for the specific Framework use cases.

Back to Implementation FAQ

Questions

(add a question if you have one)

Recommendations

Understand the architecture and the message flow of the Framework

Makes sure you understand the architecture, the business rules as well as the message flows as described in the Framework. The application users have to be aware of the key aspects of the framework as well.

Being conformant to a Framework has consequences for internal interfaces

The applications within the organization need to support the business models as defined by the Framework. The Framework therefore has a serious impact on the HL7 version 2 (and other) interfaces within an organization. HL7 version 2 interfaces are likely to be used for many years to come. There is a requirement for more rigour in the use of HL7 v2, as HL7 v3 is much richer in content.

All of the above means that one shouldn't/can't ignore the "internal" interfaces if inter-organizational v3 interfaces are added to an application. i.e. one may have to change/improve the existing v2 interfaces.

Avoid "lock-in" of the application into a separate VPN

Intra-organizational communication requires a secure environment. In order to guarantee a secure environment a Framework may specify that all communications have to take place using one specific VPN network. This creates a conflict with the need to have access to corporate network (or internet access in general), e.g. for the ordering of supplies. Such issues have to be resolved with the organization responsible for the creation of the Framework.

Maximize the utilization of registries

If the Framework architecture contains registries for patients, care providers or insurance details, retrieve the latest available data from these registries before including it in outbound messages or documents.

Get knowledge about security issues

For many IT vendors in healthcare, security requirements for inter-organization communications are a new topic. Familiarize yourself with the security aspects of the Framework, as well as with other commonly used standards in this area.

Support multiple versions of interactions

The Framework is likely to periodically publish new versions of existing interactions. During a specified transitory phase an application will need to support multiple versions of an interaction. The underlying business process for different versions of an interaction may also be slightly different.

Address how non-Framework flows will co-exist

There will be existing interfaces that are not consistent with the framework that need to be maintianed, and there will also be flows for which there is a "bottom-up" business rationale that are not supported by the framework. This does happen and needs to be managed, ideally in a way that can cleanly converge with the framework. The use of open standards are critical here. Also clear Information Governence rules need to be available to set realistic requirements on such flows. If this is not recognised then there will be too much pressure on the framework to deliver everything, and too much dependance on the framework to meet short term tactical needs.

During the August2006 IHIC conference it was noted that an issue may occur if (on the initiative of providers and/or vendors) an extension of the Framework is created, which is not "accepted"as such by the Framework organization. The Framework organization may have other priories (or may not have the budget) to do a full accreditation of the extension. This means the extension ends up being used in paralel to the Framework infrastructure, and that one can't use the transport infrastructure nor registries (e.g. patient/provider rehistries) as present under the Framework. This may cause a duplication at the infrastructural level.