General screening criteria can be applied to screen available standards for implementation with a solution. It is assumed that the standards in use with existing systems participating in the solution will be evaluated as part of the initial screening, as well as options for resolving any differences between existing, implemented standards and those selected.
HTML |
---|
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/css/bootstrap.min.css"> <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.6.1/css/font-awesome.min.css"> <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.12.0/jquery.min.js"></script> <script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/js/bootstrap.min.js"></script> <span> <h4><i class="fa fa-angle-right fa-2x" style="color:rgb(220,90,35)"></i> <b>Review <a href="#fit#GeneralStandardsScreeningCriteria-fit">Fit for Purpose Criteria</a></b></h4> <h4><i class="fa fa-angle-right fa-2x" style="color:rgb(220,90,35)"></i> <b>Review <a href="#steward">Stewardship Criteria</a></b></h4> <h4><i class="fa fa-angle-right fa-2x" style="color:rgb(220,90,35)"></i> <b>Review <a href="#quality">Quality Criteria</a></b> </h4> </span> |
Anchor | ||||
---|---|---|---|---|
|
Fit for purpose criteria evaluate the appropriateness of the standard for the intended business, clinical and technical context by considering whether the standard: aligns to the eHealth Blueprint; is an existing standard; supports the business requirements; supports the technical requirements; is likely to be adopted; and supports coded and free text content. [Office1]
Table 1 - Fit for Purpose Criteria
Criteria | Description | Rationale |
Alignment to the eHealth Blueprint | The purpose of this criterion is to assess whether the standard supports the exchange of information between two or more components of the EHR. The standard should also be intended to be used in a federated approach to EHR architecture where multiple organizations are expected to build, operate and/or host the various applications. | The standard supports eHealth mandate in providing a single, harmonized, coherent province-wide EHR. |
Existing Standard [RB2]
| This criterion assesses whether the standard is adopted/adapted from existing standards, and whether it is intended for international, pan- Canadian.
| Re-use of existing standards allows implementers to re-use code (i.e. in point of service /Health Information Access Layer (HIAL) applications, conformance testing environments, etc.). It also allows reuse of existing tools/skills/knowledge sets to establish the standard.
|
Supports Business Requirements | This criterion assesses whether the standard expresses all information required by the business/clinical domain. While the exact business requirements are project specific, example questions may include:
| To ensure that the standard addresses the health care business requirements.
The standard should be health care delivery setting independent to enable use across multiple health care delivery settings. |
Supports Technical Requirements | This criterion assesses the degree to which the standard is feasible to adopt and implement according to the technical requirements of the project. While the exact technical requirements are project specific, example questions may include:
| To enable successful implementation of the standard. |
Likely to be Adopted[Office3] | This criterion assesses the likelihood that the selected standard will be adopted and maintained by vendors and other implementers. Some questions that may be asked when assessing the likelihood for adoption, include:
| To ensure success of the implementation. If the standard is not widely implemented or supported by vendors, it will result in increased time, cost, and effort. |
Supports coded and free text content.
| This criterion assesses the degree to which coded data is required. Some questions to ask when assessing whether there is a need for coded data versus free text, may include:
| Different standards support different levels of data granularity and coding. However, there can be trade-offs to application developers and users to provide granular and coded data. At one extreme, end users may reject using the application because it forces them to enter data in too many fields, increasing their time/effort to do so. At the other extreme, just capturing free text can cause privacy breaches and be a barrier to implementing decision support. |
Anchor | ||||
---|---|---|---|---|
|
Stewardship criteria facilitate comparison of the standard‘s steward in terms of governance structure, licensing and intellectual property rights, and defined maintenance process.
Table 2 - Stewardship Criteria
Criteria | Description | Rationale |
Costs and Benefits of Implementation | This criterion assesses whether the cost of implementation and disruption to current business is affordable given the benefits. It is important to consider not only the initial cost but the on-going cost for maintenance as well. Cost is not only measured in currency, but can be in time or effort as well. Some sample questions to ask when assessing the costs and benefits of implementation, include:
| To take into consideration any cost constraints when adopting a standard, as well as initial implementation and longer-term maintenance costs.
|
Governance Structure | The purpose of this criterion is to assess whether or not the standard is governed appropriately. When assessing if a governance structure is in place, it is important to consider whether there are:
| To ensure proper processes are in place for the voting, maintenance and changing of the standard amongst its various stakeholders; as well as certification and other capabilities of the standards development or maintenance organization. |
Intellectual Property and Licensing Costs | This criterion assesses whether the intellectual property and licensing terms for the standard allows the wide use of the standard. Example questions may include:
| To ensure that the standard is vendor neutral and allows for the wide use of the standard. Openness and intellectual property policies affect the status, uptake and implementability of specifications, especially in the long term. |
Defined Maintenance Process | This criterion assesses whether or not the standard custodian has processes in place to accept requests for change to address errors or new needs in the standard. When assessing if a maintenance process is in place, it is important to consider the following:
| Business requirements and technology change over time, as such, standards need to evolve to meet changing needs. It is therefore important to ensure the selected standard has defined maintenance processes in order to evolve. |
Anchor | ||||
---|---|---|---|---|
|
Standard quality criteria evaluate the overall calibre of the standard and are not related to the standard content itself. They must enable interoperability, be adaptable, and stable. Additional implementation resources must exist, such as training, implementation guides, and software to support development, conformance testing, and maintenance of the standard.[Office1]
Table 3 - Standard Quality Criteria
Criteria | Description | Rationale |
Provides Implementation Support and Education[Office2] | To assess the degree to which resources are able to assist with appropriate use and implementation of the standard. Some key questions to consider when assessing this criteria are:
| If there are organizations available to provide supporting services to help implement, it will help increase the number of adopters and decrease the costs for specific implementers who would otherwise have to provide those services. |
Enables Interoperability | The purpose of this criterion is to assess whether the standard is complementary to or strategically positioned to work with existing interoperability standards implementations. When assessing this criterion, the following should be considered:
Note: Consider how components of an integrated solution interact as well as any enabling services when assessing the costs, benefits and risks of the items above[Office4] . | To enable existing and new clinical solutions and provide the capability of exchanging information in a seamless manner. To ensure that previous data and legacy systems are compatible with the standard and can be upgraded if necessary. |
Implementation and Maintenance Tools | This criterion assesses the availability of tools, code libraries, and/or COTS products to support implementation and maintenance of the standard. The following are questions that may be asked:
| The existence of tools that are easily accessible decreases the effort and cost to implement and maintain a particular standard. |
Conformance Testing Methodologies and Tools | This criterion assesses if the standard has well defined conformance testing processes and supporting tools. Examples questions may include:
| In order to test whether a standard has been implemented correctly, a set of conformance criteria and profiles against which a standard can be measured is important. Ideally, a process to measure conformance should be in place to publicly notify those vendors that are certified (meet testing criteria). |
Proven Stability [Office5] | This criterion assesses the stability and level of adoption of the standard. Some key questions to consider are:
| If a standard is stable and widely implemented it is more attractive for other implementers to adopt it. If a standard is still in inception, it is more volatile and fragile, which will likely lead to increased risks (e.g. increased implementation costs and timeline delays) for initial implementers. |
Adaptable and customizable [Office6] | This criterion assesses the extent to which the standard allows implementers to make modifications to meet local requirements. Example questions may include:
| For every interoperability standard, it is essential to describe how tightly the aspects defined in the standard constrain the options for the implementation, and which aspects are left for the implementation-specific or customer-specific conventions.
|