I. Category/Classification
Framework
II. Standards Development Organization (SDOs)
Institute of Electrical and Electronics Engineers (IEEE)
P1157.1 (MEDIX) Joint Working Group for a Common Data Model
III. ANSI Accreditation
IEEE is an ANSI accredited organization
IV. Name of framework, architecture or model
Trial Use Standard for Healthcare Data Interchange - Information Model Methods
V. Contact for More Information:
George W. Beeler, Jr.
Email: beeler@mayo.edu
voice, 507-284-9129
fax, 507-284-0796.
VI. Description of framework, architecture or model
The following paragraphs derive directly from the scope and purpose statement of the draft standard.
Scope:
This standard specifies the recommended approach for modeling the health care environment in an object-oriented paradigm. It is intended for use by organizations developing standards for information interchange between health care information systems. This standard specifies the graphical and textual notations used in defining the information model, and procedures for defining conformance and compliance. This standard also specifies procedures for evolving the information model.
This standard defines notations and recommends procedures for development of standardized components of an overall object-oriented information model to be used in health care data interchange. The use of consistent notation and procedures facilitates modular development of the overall model and facilitates the development of a family of standards to provide for health care data interchange
The intent of this framework specification is to provide a common way for healthcare information standards organization to develop their information models, in order to facilitate comparison and sharing of those models between SDO's. Implementation of this standard requires no particular tooling. Complete specification of information model can be derived from a literary expression created with a word processor.
It should be noted that the development of this framework was done as a Joint Working Group drawing members from ASC-X12N, ASTM, DICOM, HL7, and IEEE.
VII. Readiness of framework, architecture or model
Two drafts of this framework have been published - in 1994 and 1996. The 1996 draft has been freely circulated to interested parties in a variety of healthcare information interchange organizations.
Electronic reproductions of the April 1996 release can be obtained at http://www.mcis.duke.edu/standards/ieee/jwg-model/ in files stdmain.pdf and stdanex.pdf.
This framework has been implemented in the modeling activities of at lease HL7, ASC-X12N, and DICOM.
The full framework is available. Extensions to incorporate use-case modeling and related models are under consideration. The P1157.1 committee intends to seek a ballot on this document in 1997.
This framework is not dependent on the availability or selection of any particular tool. Indeed, several tools currently on the market will support modeling in this methodology. The use of the framework is not dependent on any RFI or RFP process.
VIII. Indicator of Market Acceptance
Over 150 paper copies have been produced and distributed. It is not known how many electronic copies have been acquired. The methodology has been implemented in at least three SDO's as part of their own information modeling activities. This framework is not known to be in use in other countries.
HL7 is committed to using this framework as part of its larger message development framework for Version 3.
IX. Level of Specificity
I am uncertain of the intent of this question and therefore cannot respond.
X. Identifiable Costs
Cost of acquisition will involve simply the purchase cost of a copy of the standard from the IEEE on the order of $100 to $400. Additional costs to adopt a compatible framework within any given SDO are entirely dependent upon the technological and political preparedness of that SDO to move to a formalized, model-based methodology.
Project #: P1157.1
Title: Standard for Healthcare Data Interchange - Information Model Methods
Scope: The scope of this document is to specify the approach used within the P1157 family of standards for modeling the health care environment in an object-oriented paradigm. This document specifies the graphical and textural notations used in defining the information model, procedures for registration of globally unique identifiers, and procedures for defining conformance and compliance. This document also specifies procedures for evolving the information model and for defining local specializations. The scope of the family of standards is to provide for healthcare data interchange in the open systems environment.
Purpose: This document defines notations and procedures for development of standardized components of an overall object-oriented information model for use in P1157 healthcare data interchange. The use of consistent notation and producers facilitates modular development of the overall model. The purpose of the P1157 family of standards is to provide for healthcare data interchange in the open systems environment.
Project #: P1157.1.1
Title: Standard for Healthcare Data Interchange - Common Healthcare Objects
Scope: The scope of this document is the specification of common healthcare objects which are the basis for specialization by other standards in the P1157.1 Information Model.
Purpose: The purpose of this document is to provide a common repository for base object classes which are used by multiple standards in the P1157.1 Information Model. The use of a common set of base objects is intended to promote consistency in the specializations defined by other standards in the P1157.1 Information Model.
Project #: P1157.1.2
Title: Standard for Healthcare Data Interchange -Registration Admission/Discharge/Transfer
Scope: The scope of this document is the specification of an object-oriented model of the subject domain of patient Registration, Admission, Transfer, and Discharge.
Purpose: The purpose of this document is to provide an object oriented model which supports the specification of healthcare data interchange transactions involving the subject domain of Registration, Admission, Discharge, Transfer.
Project #: P1157.1.3
Title: Standard for Healthcare Data Interchange - Laboratory
Scope: The scope of this document is the specification of an object-oriented model of the subject domain of Laboratory including, but not limited to, Chemistry, Hematology, Immunology, and Microbiology. There may also be application in Anatomical pathology, that is, Cytology, Histology, and Autopsy.
Purpose: The purpose of this document is to provide an object oriented model which supports the specification of healthcare data interchange transactions involving the subject domain of Laboratory.
Project #: P1157.1.4
Title: Standard for Healthcare Data Interchange - Radiology
Scope: The scope of this document is the specification of an object-oriented model of the subject domain of Radiology.
Purpose: The purpose of this document is to provide an object oriented model which supports the specification of healthcare data interchange transactions involving the subject domain or Radiology.
Project #: P1157.2
Title: Standard for Healthcare Data Interchange -Interchange Format Methods
Scope: The scope of this document is the definition of the methods used for specification of standardized transactions in theP1157 family of standards. This document defines the models for mapping from the information model defined by the P1157.1.n standards to standardized transactions for healthcare data interchange. Wherever possible, the interchange formats and representation profiles used by this family standards will consist of specialization's of F-type International Standardized Profiles (ISPs)as defined by ISO TR 10000.
Purpose: This document provides a model for message specification at the application level for the P1157 family of standards. The model forms the basis for specification of messages based upon particular interchange formats and representation profiles. The goal is to leverage F-type ISPs wherever possible, focusing on specialization for the needs of healthcare data interchange where necessary.
Project #: P1157.2.1
Title: Standard for Healthcare Data Interchange -EDI/EDIFACT Interchange Formats
Scope: The scope of this document is the specification of standardized transactions for healthcare data interchange based upon the interchange formats defined by ANSI X.12 EDI and ISO 9735EDIFACT. The messages defined by this standard are based upon the Healthcare Information Model defined by the P1157.1.n standards.
Purpose: The purpose of this document is to define the implicit and explicit event driven mapping of the Healthcare Information Model defined by the P1157.1.n standards to the interchange formats defined by ANSI X.12 EDI and ISO 9735 EDIFACT.
Project # : P1157.2.2
Title: Standard for Healthcare Data Interchange -ODA/ODIF/SGML Interchange Formats
Scope: The scope of this document is the specification of standardized transactions for healthcare data interchange based upon the document architecture and interchange formats defined by the ISO8613 ODA/ODIF family of standards and the ISO 9069 SGML Document Interchange Format.
Purpose: The purpose of this document is to define the implicit and explicit event driven mapping of the Healthcare Information Model defined by the P1157.1.n standards to the interchange formats defined by the ISO 8618 ODA/ODIF family of standards and the ISO 9069 SGML Document Interchange Format standard.
Project #: P1157.2.3
Title: Standard for Healthcare Data Interchange - CMIS/CMIP Interchange Formats
Scope: The scope of this document is the specification of standardized transactions for healthcare data interchange based upon ISO 9595 Common Management Information Service and ISO 9596 Common Management Information Protocol.
Purpose: The purpose of this document is to define the implicit and explicit event driven mapping of the Healthcare Information Model defined by the P1157.1.n standards to application transactions supported by the services and protocols defined by CMIS/CMIP.
Project #: P1157.3
Title: Standard for Healthcare Data Interchange -Communication Profile Methods
Scope: The scope of this document is to define the procedures for specification within the P1157 family of standard of standardized functional profiles for healthcare data interchange. The profiles correspond to the A/B Application profiles, T/UT transport Profiles, and R Relay Profiles as defined by ISO TR10000.Wherever possible, the standardized profiles defined in this family of standards will be based upon specializations of International Standardized profiles (ISPs).
Purpose: The purpose of this document is to define a common set of procedures for use in specification of the communication profiles for healthcare data interchange. Wherever possible, theP1157 family of standards will leverage International Standardized Profiles.
Project #: P1157.4
Title: Standard for Healthcare Data Interchange - Semantics and Knowledge Representation of the Medical Record
Scope: The scope of this standard is the specification of the architecture for representation and interchange of the medical record in the open systems environment. Specific issues associated with preservation of the semantics of the medical record in healthcare data interchange will be addressed in this standard.
Purpose: The purpose of this document is to provide an architectural model for interchange of the medical record in the open systems environment. The goal is to build upon and extend the framework for healthcare data interchange which is developed by other standards in the P1157 family of standards.
Project #: P1157.5
Title: Recommendation for Healthcare Data Interchange - User Needs
Scope: The scope of this document is to describe the needs of users in the healthcare sector in the area of healthcare data interchange.
Purpose: This document describes the user needs with respect to healthcare data interchange. As such it serves as an introduction and tutorial for the P1157 family of standards. Overview of IEE 1157 MEDIX Project
Jack Harrington
Chair, IEEE P1157
Principal Systems Architect
(P) 508-659-3517
(F) 508-686-1319
(E) jackh@an.hp.com
Check out our Web page at
http://www.linkmib.com/linkmib
I. Category/Classification
Information model
II. Standards Development Organization (SDOs)
Quality Assurance/Data Modeling Committee of Health Level Seven (HL7).
III. ANSI Accreditation
HL7 is an ANSI accredited standards developing organization.
IV Name of framework, architecture or model
Health Level 7 Reference Information Model (RIM).
V Contact for More Information:
George W. Beeler, Jr.
Email: beeler@mayo.edu
voice: 507-284-9129
fax: 507-284-0796
VI Description of framework, architecture or model
This will be an object-oriented information model of the classes present in the healthcare domain about which Health Level 7 messages are transmitted. Its purpose will be to provide the precise definition of the content of HL7 messages. The Reference Information Model will be part of a set of models which include a Use-Case Model, the Reference Information Model, an Interaction Model, and a Message Specification Model. Each of these is linked and interdependent.
The scope of the Reference Information Model is the healthcare domain in general, with particular attention to clinical care activities within healthcare. This is the same scope as the HL7 organization. This model has not yet been implemented. It will see its initial draft presentation and evolution at the HL7 working group meetings in January 1997. No special tooling is required to read and review the model, as it will be fully specified by its literary and graphic expressions. A processable form of the model will available as a database in Microsoft Access.
VII Readiness of framework, architecture or model
The Reference Information Model is currently undergoing its initial draft development pointing towards review and use within the Technical Committees of HL7 in January of 1997. Draft version 0.6 of the HL7 RIM can be found at http://wwww.mcis.duke.edu/standards/hl7/data-model/hl7/modelpage.html. This web-site provides access to a literary expression in Microsoft Word, html expressions, graphic expressions, and the Access database.
The current release is a draft version. As with every data model, there will never be a "final version." The reference information model will evolve as the developments within HL7 continue to expand. Implementation of this model involves its use in the definition of healthcare information interchange messages. This process will begin in January 1997.
The present release of the RIM is relatively complete in scope. It will undergo further development in terms of adding additional detail to the Version 0.6 currently available. Additional releases of the DRAFT RIM are planned on a monthly basis between now and the HL7 working group meetings in January. Subsequent to that, the Reference Information Model will probably be updated in preparation for each subsequent HL7 working group meeting. HL7 has not yet determined whether (or how) to manage releases of the RIM for use external to the HL7 Working Group MDF process.
The use of the model is not dependent upon a particular set of tools. However, for an organization to use the full message development framework, tooling will be a necessary support activity. The selection of such tools for use by HL7 will occur during 1997. The use of the model is not dependent on any RFI or RFP process.
VIII Indicator of Market Acceptance
Because the Reference Information Model is being published electronically, we do not have a count on how many have been requested or distributed. This development of this model drew upon models from a number of vendor and healthcare provider organizations. It has been provided back as a courtesy to those same organizations. It is uncertain the degree to which they will take advantage of it.
Presumably, the reference information model will be used by the HL7 affiliates in Germany, the Netherlands, Canada, and New Zealand. No other SDO's are committed at this time.
IX Level of Specificity
I am uncertain of the intent of this question and therefore cannot respond.
X Identifiable Costs
Expenses have not yet been fully established, but it assumed that licensure costs would be nominal, on the order of $250, if HL7 elects to publish versions of the RIM for external use.
I. Category/Classification
Framework
II. Standards Development Organization (SDOs)
Developed by the Quality Assurance/Data Modeling Committee of Health Level 7
III. ANSI Accreditation
HL7 is ANSI Accredited
IV Name of framework, architecture or model
Message Development Framework for HL7 Version 3
V. Contact for More Information:
George W. Beeler, Jr.
Email: beeler@mayo.edu
voice: 507-284-9129
fax: 507-284-0796
IV. Description of framework, architecture or model
The intent of this framework is to provide a methodology for developing healthcare information interchange messages. This methodology will be used for HL7 Versions 3.0 and beyond. The framework defines all of the steps in the message development process to be used by HL7. It includes the criteria for passing from step to step and the methods of documentation of the deliverables at each step.
The scope of applicability of the framework is healthcare information interchange standards. The messages defined as a result of this process may be implemented either as ASCII strings in a variety of formats or as data structures that can be interchanged with a variety of object-based protocols.
The framework is based upon a set of fully defined inter-linked models of the healthcare and messaging environment. It includes a Use Case Model for the standard; an Information Model for the healthcare domain about which messages are being sent; an Interaction Model that specifies the roles of systems that are exchanging information according to these standards; and a Message Specification Model which can be transformed to support a variety of information interchange protocols.
The framework has been used in prototype situations within HL7. It will be implemented as a working framework in January 1997. The necessary tooling to support the framework and the methodologies within the framework will be selected but have not been selected at this point.
VII. Readiness of framework, architecture or model
Versions of this framework have been published and distributed at HL7 meetings. The most recent version (as of November 6, 1996) can be found at http://www.mcis.duke.edu/standards/hl7/pubs/version3/mdf_0896.zip. A subsequent draft will be released about January 1, 1997.
This is a draft framework. Even after it is implemented, it will undergo continuing evolution. It has only been implemented in prototype circumstances. It will be brought into full use in January 1997.
The draft referenced above is relatively complete, but the level of detail varies in different sections of the framework. As noted, the more or less final version is intended for delivery at the HL7 meetings the third week of January 1997.
This framework is not dependent on the availability of any particular tool. It will, however, be necessary to provide tooling for an organization such as HL7 to take full advantage of such a framework. There is no dependence on an RFI or RFP process.
The overall process upon which this framework is based derives from the CEN TC251 activities. Although the process is not applied to a large organization, the CEN efforts do provide an existence proof that this methodology will lead to usable message standards.
VIII Indicator of Market Acceptance
As this framework has been published electronically, we cannot tell how many copies have been requested or distributed.
The suggestion that we respond as to plans for vendors or government agencies to use this specification seems at odds with the declared scope for the inventory said "those FAMS which promote interoperability among healthcare information standards." This framework is designed to be used within a standards organization to develop compatible, model-based message specifications. Thus, it seems unclear how many vendors or government agencies might use this framework. At present, we know only of plans to use it within HL7.
A similar methodology was developed by CEN TC251. The HL7 MDF is based on that prior work and has acknowledged that work.
IX Level of Specificity
I am uncertain of the intent of this question and therefore cannot respond.
X Identifiable Costs
Costs for using this framework are not fully known. Cost of licensure from HL7 will be nominal, on the order of $250 to purchase a copy of the specification. Time frames for education, training, and implementation are entirely dependent upon the readiness of the organization adopting this framework to step up to the technological concepts embedded within it. It needs a group that is at least comfortable with object-based modeling and object-related specifications.
American Dental Association (ADA) Computer-Based Oral Health Record
The American Dental Association (ADA) is sponsor and secretariat of the Accredited Standards Committee (ASC) MD156 for Dental Materials, Instruments and Equipment. In 1992 there was interest in the standardization of clinical information systems. After evaluating current informatics activities, the ADA initiated several projects relating to clinical technology. A task group of the ASC MD156 was created by the Association to initiate the development of technical reports, guidelines, and standards on electronic technologies used in dental practice.
Components of the task group include five working groups for clinical information systems. The working groups were established to promote the concept of a dental computerized clinical work station and allow the integration of different software and hardware components into one system in order to provide for all of a clinician's information needs. Clinical information systems include all areas of computer-based information technologies such as digital radiography, digital intraoral video cameras, digital voice-text-image transfer, periodontal probing devices, CAD/CAMs, etc. By establishing standards for these modules, the need for several stand-alone systems in the dental office will be eliminated.
Each working group encompasses a broad spectrum of projects under a central theme. Within each working group, subcommittees are responsible for the specific projects. Each subcommittee has been researching standards already in existence to determine if they could be applicable to dentistry. Participants are also interfacing with standards groups active in medical informatics.
The ADA also sponsors participation in ANSI activities of the International Organization for Standardization (ISO) Technical Committee 106 on dentistry and acts a secretariat for ANSI for Working Group 2 of ISO/TC 106. Thus, the ADA works both nationally and internationally in the formation of standards for dentistry.
The American Dental Association has been sponsoring a standards program for dental materials, instruments and equipment since 1928. From 1928 to 1953, all specifications for dental materials, instruments and equipment were developed at the national Bureau of Standards by the federal government in cooperation with the ADA. Between 1953 and 1970, the Dental Materials Group of the International Association of Dental Research (IADR) acted as advisory to the ADA in developing specifications. In 1970, American National Standards Committee MD156 (ANSC MD156) was established by the American National Standards Institute, replacing the Dental Materials Group. In 1983, the ANSC MD156 became an accredited committee by ANSI making the committee the Accredited Standards Committee MD156 (ASC MD156).
To date, 56 specifications for dental materials, instruments and equipment have been adopted by ANSI as American National Standards. In addition, the ADA acts as proprietary sponsor on a project to handle standards for dental radiographic film. This activity is conducted under the Accredited Canvas Method of ANSI.
Name of Standard Framework, Architecture or Model: (1) Proposed ANSI/ADA Specification 1000: Standard Clinical Data Architecture for the Structure and Content of a Computer-based Patient Record. This standard is being developed for based Oral Health Record (COHR). The objective was to develop COHR features which would offered the greatest utility to the profession as a whole, addressed issues of open architecture and would be technology independent. The baseline version 1.0 of the COHR Concept Model was released in February 1996. While the process and data models described in the COHR were specific to dentistry, these models were developed with the understanding that dentistry is a microcosm representative of the entire health care environment. Early in the modeling of the COHR the ADA addressed integrated care delivery and coordinating care among the various health care professions and delivery environment. The COHR was developed as a progression of analytical models founded on clinical and public health principles. It described the health care environment, the fundamental processes of health care delivery and the data needed to support these processes. The COHR Concept Model was subsequently converted into a logical data model by the ASC MD156. The logical model was expanded and modified through input from physicians, nurses and allied health personnel. This modification evolved the COHR logical model into a generic clinical data architecture for patient health care information independent of health care profession or delivery environment.
Purpose: To present an organizing framework for the specification of a clinical data architecture and components via a fully attributed logical data model.
Scope and/or environment: This specification applies to the application data interface (the conceptual interface in the Codasyl Three Tier Architecture) of computer system architecture.
A. Type: Fully attributed logical data model.
In what way will this FAM be implemented/used? To guide development of databases for patient information, clinical repositories, etc.
B. Modeling or other tools required: None.
Objectives: This specification will ultimately make healthcare information seamlessly available at the time and point of care to all authorized users, in a form best used, and with no compartmentalization by profession, specialty, discipline, or care delivery environment. Seamless data interface among system users serving private practice, academia, research, industry, and government programs will offer significant benefits to all system users.
Functions: This specification presents a generic conceptual model of the clinical process, and the data required to enable these processes. From this concept model a logical data model is developed for a clinical data architecture appropriate for use in computer-based patient records and other applications.
Healthcare domain completeness: This specification is independent of health care profession and specialty. It is appropriate for the health care supporting industries, for the educational and research establishment, and for veterinary care.
Provider/payer user environment: The specification is independent of and appropriate across the range of practice philosophy, patient management approach, and reimbursement mechanism.
Systems environment: The specification applies uniformly to flat file, x-base, relational and object-oriented data management approaches.
Systems domain focus: The specification details the architecture of the Application-Data Interface of clinical systems, and therefore provides a foundation data structure useable by standards operating at a higher level of the CODASYL architecture.
Other relevant characteristics: The specification was prepared using a formal conceptual process and data modeling, with preparation of the logical data model and data characteristics through consensus of subject matter experts, consistent with the ANSI Accredited Canvass Method.
Implementation guides and concordances with prominent existing and emerging standards will be prepared. Clinical software intended for use in dentistry may be voluntarily submitted by the vendor for conformance evaluation by the ADA under an evaluation program similar to its seal of approval program. The specification is under development: data models are complete, first two of 18 parts have been drafted and revised from public comment. Remaining parts of the specification are being prepared for public review in 1997.
A. Has it been published? Yes, initial parts but the American Dental Association, Summer of 1996.
B. Is it a draft or a final version? Draft for public comment.
C. Has it been implemented? If so, where and when? No
D. If the FAM is under development, what portions of it are available now?
Parts 1000.0 and 1000.1 are now available.
E. What are the target dates for additional portions or versions of the FAM?
Parts 1000.2 through 1000.17 will be completed by the Summer of 1997.
F. Is the use of this FAM dependent on the availability/selection of a tool? No.
G. Is the use of the FAM dependent on an RFI, an RFP or other evaluation or selection of a tool? No.
A. How many copies have been requested and distributed? Over 1000 copies of the draft documents have been distributed for review. Approximately 2000 copies of the foundation concept model document in two printings were distributed for public review and comment during 1995-96.
B. Which SDO's are committed to comply with or use this FAM? American Dental Association.
C. Please not any other relevant indicators of market acceptance within the public or private sector. The specification is being coordinated with ASTM E31-19 as an implementation vehicle for ASTM E31-1384 and other standards.
The specification applies to the middle tier of the CODASYL Three-Tier Architecture. The specification identifies the metadata for entities and attributes needed to construct a physical database containing clinical data, e.g. data name, type and length, format, values, null option, and entity data usage. The specification requires ASCII character set, and where precluded by language UNICODE is required. The specification is code set independent: the data model allows user selection of any existing code set such as CDT, ICD-9, CPT, SNOMED, etc., and user definable code sets for use in reference or look-up tables. The specification requires the use of several ANSI and ISO standards.
Relationships with other standards:
The prominent existing and emerging standards relevant to this specification are ASTM (1239, 1384, 1633, 1715, 1744, 1769, and others, along with proposed standards for the longitudinal automated record and drug therapy documentation), NCPDP, ANSI X-12, DICOM, HL7, and ISO (8601, etc.).
No overlap or conflict exists since the relevant standards apply to a higher level of the CODASYL system architecture. Relevant ISO standards are required in this specification.
Documents and data dictionaries are being assembled from the standards organizations for harmonization: identical data names are used where possible, and cross mapping will be provided where commonality is not feasible. Harmonization is currently underway between DICOM, ASTM E31.19 and ASC MD156. ASC MD156 is also participating in ASTM E31.23 modeling.
Acquisition of the specification will be through normal publication routes by ANSI or the ADA. There is no license fee associated with the specification. However, ANSI or the ADA may charge for the publication of the specification and its implementation guides and concordances. The specification is expected to reduce cost of design and development of clinical information systems by providing a database blueprint and design metadata.
Computer-based Patient Record Institute
III. ANSI Accreditation, ANSI Accreditation applied for or not ANSI
Accredited
Note: A) If your organization is ANSI accredited, what is the type
and scope of accreditation? For example, is it
Accredited Organization Method, Accredited Standards
Committee Method or is it Accredited Sponsor using
Canvas Method? If not, have you applied for
accreditation?
Not ANSI Accredited
IV. Name of Standard
Note: A) Include the name followed by the number of the standard,
if a number is available.
V. Contact for more information
Note: A) Include name, E-mail address, phone and fax number.
Margaret Amatayakul
Executive Director
Computer-based Patient Record Institute
1000 East Woodfield Road., Suite 102
Schaumburg, IL 60173
TEL. 847-706-6746
FAX. 847-706-6747
E-MAIL. CPRINET@AOL.COM
VI. Description of Standard
Notes: A) Include separate statements for:
- objectives:
Objectives:
The objectives of Computer-based Patient Record Description of Content provides detailed information about the dimensions of the computer-based patient record. It defines information content, information representation, and time span. As well, it briefly describes migration from paper-based medical record systems to the expansive vision of the computer-based patient record presented by the Institute of Medicine (The Computer-based Patient Record: An Essential Technology for Health Care, National Academy Press, April 1991).
Functions
The primary function of Computer-based Patient Record Description of Content is to assist in understanding of the scope of the content of the computer-based patient record.
- user environment (reimbursement, administrative,
clinical and/or other functional areas)
User Environment
Computer-based Patient Record Description of Content is applicable to any provider implementing computer-based patient records, or any vendor developing CPR systems.
- systems environment (operating systems, network,
hardware or other requirements)
- Application function/domain completeness (Within the
defined scope of this standard, what functions/codes
are complete?
Functionality
Computer-based Patient Record Description of Content may be used alone, or in conjunction with other CPRI descriptive materials. It is not dependent upon other standards.
- In what way(s) is this standard superior to other
standards in this category/classification?
Competing Standards
To our knowledge there is no other descriptive document serving this purpose.
- any other relevant characteristics
VII. Readiness of Standard
Notes: A) Is it a guideline? If so, does it address policy, process, practice or design?
Guideline:
Computer-based Patient Record Description of Content addresses design.
B) Is it implementable? (If so, is it fully or partially implementable?, explain)
Implementable
Computer-based Patient Record Description of Content is implementable by any organization that wishes to use it as a tool for planning.
C) How can the standard be obtained?
Obtainable
Computer-based Patient Record Description of Content is available on CPRI's web site (http://www.cpri.org). Paper copy can be obtained for a nominal fee from the Computer-based Patient Record Institute.
D) Does it require a separate implementation guide? (If so
is the guide approved by the SDO?
Implementation Guide
Not required.
E) Is there only one implementation guideline (or are there
major options that impact compatibility)?
Comformance Standard Specification
Since this is a guideline, conformance testing is not applicable
F) Is a conformance standard specified?
G) Are conformance test tools available?
H) Source of test tools?
I) If the standard is under development, what parts of it
are ready now?
Development Stage
Computer-based Patient Record Description of Content is final and was released in April 1996.
J) What extensions are now under development?
Extensions
Discussions are underway to develop an object-oriented view of computer-based patient records which may ultimately, but not at this time, substitute for this work.
K) What are the major milestones toward standards
completion?
L) What are the projected dates for final ballotting and/or
implementation?
M) Please note any other indicators of readiness that may
be appropriate.
VIII. Indicator of Market Acceptance
Notes: A) If the standard is a guideline, how many copies have been
requested and distributed?
Market Acceptance
No information is available about sales of this relatively new product.
B) If the standard is an implementable standard, how many
vendors, healthcare organizations and/or government
agencies are using it?
C) Is this standard being used in other countries (which
are they)?
D) Please note any other relevant indicator of market
acceptance within the public or private sector.
IX. Level of Specificity
Notes: A) If your standard is a guideline, how detailed is it?
B) If it is an implementable standard, describe how
detailed its framework is and its level of granularity.
C) Does the standard(s) reference or assume other standards
to achieve more specificity?
D) If it includes or assumes code sets, which ones are they?
E) What is the description of the code set?
F) How is the code set acquired?
G) Is there a users' guide or some other assistance
available on the code set?
H) If the code set is currently in use, what is the extent
of its use (e.g., approximate number of users)?
I) If the code set is under development, what are the
projected dates of completion and implementation?
X. Relationships with other standards
Notes: A) Identify other standards and the relationship(s) with
other standards such as inclusion, dependency, interface overlap, conflict or coordination.
B) Identify specific standards reconciliation or
coordination activities.
C) What portion of the specification and functionality is
affected by this coordination?
D) What conditions are assumed in order for this
coordination to be effective?
E) Is this standard consistent with international standards?
If so, which standards?
F) What gaps remain among related standards that should be
addressed?
G) Describe what is being done to address these gaps.
XI. Identifiable Costs
Notes: A) Please indicate the cost or your best estimate for the
following:
Cost
Paper copy of Computer-based Patient Record Description of Content is available from CPRI at a cost of $15. See above for web site availability.
V. Contact for more information
Note: A) Include name, E-mail address, phone and fax number.
Margaret Amatayakul
Executive Director
Computer-based Patient Record Institute
1000 East Woodfield Road., Suite 102
Schaumburg, IL 60173
TEL. 847-706-6746
FAX. 847-706-6747
E-MAIL. CPRINET@AOL.COM
VI. Description of Standard
Notes: A) Include separate statements for:
- objectives:
Objectives:
CPR Project Evaluation Criteria is a product developed for use in the Nicholas E. Davies CPR Recognition Program conducted by the CPRI. In addition to serving as the specific criteria providers must meet for this recognition, the document may be used outside of the recognition program to:
Functions:
The primary function of CPR Project Evaluation Criteria outside of the Davies CPR Recognition Program is to help providers understand the scope of CPR systems and evaluate their progress toward that goal.
- user environment (reimbursement, administrative,
clinical and/or other functional areas)
User Environment
CPR Project Evaluation Criteria is designed to be used primarily in the understanding of computer-based patient records as they may be implemented in provider settings. They are not intended to be used to describe a specific product. CPR system implementation depends upon not only technology, but the environment in which the CPR system is implemented. The criteria includes that for management, functionality, technology, and impact.
- systems environment (operating systems, network,
hardware or other requirements)
- Application function/domain completeness (Within the
defined scope of this standard, what functions/codes
are complete?
- In what way(s) is this standard superior to other
standards in this category/classification?
Competing Standards
To our knowledge there is no other tool that provides criteria for evaluating implementation of CPR systems in provider settings.
- any other relevant characteristics
VII. Readiness of Standard
Notes: A) Is it a guideline? If so, does it address policy,
process, practice or design?
Guideline:
CPR Project Evaluation Criteria address design.
B) Is it implementable? (If so, is it fully or partially
implementable?, explain)
Implementable
CPR Project Evaluation Criteria is implementable by any organization that wishes to use it as a tool for planning, any consulting firm that wishes to use it to assist clients in evaluating progress toward implementing CPR systems, and by vendors to establish provider expectations.
C) How can the standard be obtained?
Obtainable
CPR Project Evaluation Criteria can be obtained for a nominal fee from the Computer-based Patient Record Institute.
D) Does it require a separate implementation guide? (If so
is the guide approved by the SDO?
Implementation Guide
Not required.
E) Is there only one implementation guideline (or are there major options that impact compatibility)?
Conformance Standard Specification
Traditional conformance testing does not apply, however, the CPR Project Evaluation Criteria have been pilot tested and have been used in three years of Davies CPR Recognition Program implementation.
F) Is a conformance standard specified?
G) Are conformance test tools available?
H) Source of test tools?
I) If the standard is under development, what parts of it
are ready now?
Development Stage
CPR Project Evaluation Criteria is in Version 2.1, released in March 1996.
J) What extensions are now under development?
Extensions
CPR Project Evaluation Criteria may be revised as experience with the Davies CPR Recognition Program may suggest the need, as reflected by industry advances.
K) What are the major milestones toward standards
completion?
L) What are the projected dates for final ballotting and/or
implementation?
M) Please note any other indicators of readiness that may
be appropriate.
VIII. Indicator of Market Acceptance
Notes: A) If the standard is a guideline, how many copies have been
requested and distributed?
Market Acceptance
Many copies of CPR Project Evaluation Criteria have been sold, as well as distributed as part of the Davies CPR Recognition Program. In this program, providers who have been recognized attest to the usefulness of the review process and the importance of the recognition. Recognized providers have included: Intermountain Health Care, Columbia-Presbyterian Medical Center, Department of Veterans Affairs, and Brigham & Women=s Hospital. Providers to be recognized in 1997 have not been selected as of the writing of this report.
B) If the standard is an implementable standard, how many
vendors, healthcare organizations and/or government
agencies are using it?
C) Is this standard being used in other countries (which
are they)?
D) Please note any other relevant indicator of market
acceptance within the public or private sector.
IX. Level of Specificity
Notes: A) If your standard is a guideline, how detailed is it?
B) If it is an implementable standard, describe how
detailed its framework is and its level of granularity.
C) Does the standard(s) reference or assume other standards
to achieve more specificity?
D) If it includes or assumes code sets, which ones are they?
E) What is the description of the code set?
F) How is the code set acquired?
G) Is there a users' guide or some other assistance
available on the code set?
H) If the code set is currently in use, what is the extent
of its use (e.g., approximate number of users)?
I) If the code set is under development, what are the
projected dates of completion and implementation?
X. Relationships with other standards
Notes: A) Identify other standards and the relationship(s) with
other standards such as inclusion, dependency, interface
overlap, conflict or coordination.
B) Identify specific standards reconciliation or
coordination activities.
C) What portion of the specification and functionality is
affected by this coordination?
D) What conditions are assumed in order for this
coordination to be effective?
E) Is this standard consistent with international standards?
If so, which standards?
F) What gaps remain among related standards that should be
addressed?
G) Describe what is being done to address these gaps.
XI. Identifiable Costs
Notes: A) Please indicate the cost or your best estimate for the
following:
Cost
CPR Project Evaluation Criteria is available from CPRI at a cost of $100.
CPRI Computer-based Patient Record System Description of Functionality
V. Contact for more information
Note: A) Include name, E-mail address, phone and fax number.
Margaret Amatayakul
Executive Director
Computer-based Patient Record Institute
1000 East Woodfield Road., Suite 102
Schaumburg, IL 60173
TEL. 847-706-6746
FAX. 847-706-6747
E-MAIL. CPRINET@AOL.COM
VI. Description of Standard
Notes: A) Include separate statements for:
- objectives:
Objectives:
The objectives of Computer-based Patient Record System Description of Functionality provides detailed information about the functionality (the CPR system) surrounding the core element (the CPR). It briefly describes the major benefits to be realized from a CPR system and defines the functions of data capture, data storage, information processing, information communication, security, and information presentation. The work summarizes concepts first described by the Institute of Medicine patient record study committee in The Computer-based Patient Record: An Essential Technology for Health Care, National Academy Press, April 1991.
Functions
The primary function of Computer-based Patient Record System Description of Functionality is to assist in understanding of the scope of the functionality of the computer-based patient record system.
User Environment
Computer-based Patient Record System Description of Functionality is applicable to any provider implementing computer-based patient records, or any vendor developing CPR systems.
Functionality
Computer-based Patient Record System Description of Functionality may be used alone, or in conjunction with other CPRI descriptive materials. It is not dependent upon other standards.
Competing Standards
To our knowledge there is no other descriptive document serving this purpose.
VII. Readiness of Standard
Notes: A) Is it a guideline? If so, does it address policy,
process, practice or design?
Guideline:
Computer-based Patient Record System Description of Functionality addresses design.
Implementable
Computer-based Patient Record System Description of Functionality is implementable by any organization that wishes to use it as a tool for planning.
Obtainable
Computer-based Patient Record System Description of Functionality is available on CPRI=s web site (http://www.cpri.org). Paper copy can be obtained for a nominal fee from the Computer-based Patient Record Institute.
Implementation Guide
Not required.
Conformance Standard Specification
Since this is a guideline, conformance testing is not applicable
Development Stage
Computer-based Patient Record System Description of Functionality is final and was released in September 1996.
Extensions
Discussions are underway to develop an object-oriented view of computer-based patient records which may ultimately, but not at this time, substitute for this work.
VIII. Indicator of Market Acceptance
Notes: A) If the standard is a guideline, how many copies have been
requested and distributed?
Market Acceptance
No information is available about sales of this relatively new product.
IX. Level of Specificity
X. Relationships with other standards
Notes: A) Identify other standards and the relationship(s) with
other standards such as inclusion, dependency, interface
overlap, conflict or coordination.
B) Identify specific standards reconciliation or
coordination activities.
C) What portion of the specification and functionality is
affected by this coordination?
D) What conditions are assumed in order for this
coordination to be effective?
E) Is this standard consistent with international standards?
If so, which standards?
F) What gaps remain among related standards that should be
addressed?
G) Describe what is being done to address these gaps.
XI. Identifiable Costs
Notes: A) Please indicate the cost or your best estimate for the
following:
Cost
Paper copy of Computer-based Patient Record System Description of Functionality is available from CPRI at a cost of $15. See above for web site availability.
CPR Project Scenarios
V. Contact for more information
Note: A) Include name, E-mail address, phone and fax number.
Margaret Amatayakul
Executive Director
Computer-based Patient Record Institute
1000 East Woodfield Road., Suite 102
Schaumburg, IL 60173
TEL. 847-706-6746
FAX. 847-706-6747
E-MAIL. CPRINET@AOL.COM
VI. Description of Standard
Notes: A) Include separate statements for:
- objectives:
Objectives:
The objectives of CPR Project Scenarios are to illustrate the scope of computer-based patient record systems, and to serve as a useful tool for strategic planning, requirements descriptions, and for creating test sets for live system demonstrations.
Functions
The primary function of CPR Project Scenarios is to illustrate, in understandable terms, the scope of computer-based patient records systems in multiple different views.
- user environment (reimbursement, administrative,
clinical and/or other functional areas)
User Environment
CPR Project Scenarios is designed to be used primarily in the understanding of computer-based patient records as they may be implemented for a variety of purposes. Illustrated are physician access from home, ambulatory care with patient as remote user, weekend urgent care, rural health care, inpatient care for emergency surgery, visiting nurse providing home care, public health reporting, and research.
- systems environment (operating systems, network,
hardware or other requirements)
- Application function/domain completeness (Within the
defined scope of this standard, what functions/codes
are complete?
Functionality
CPR Project Scenarios may be used alone, or in conjunction with other CPRI descriptive materials. They are not dependent upon other standards.
- In what way(s) is this standard superior to other
standards in this category/classification?
Competing Standards
To our knowledge there is no other tool that provides scenarios for visioning and strategic planning, education programs, etc.
- any other relevant characteristics
VII. Readiness of Standard
Notes: A) Is it a guideline? If so, does it address policy,
process, practice or design?
Guidelines:
CPR Project Scenarios address design.
B) Is it implementable? (If so, is it fully or partially
implementable?, explain)
Implementable
CPR Project Scenarios is implementable by any organization that wishes to use it as a tool for planning.
C) How can the standard be obtained?
Obtainable
CPR Project Scenarios can be obtained for a nominal fee from the Computer-based Patient Record Institute.
D) Does it require a separate implementation guide? (If so
is the guide approved by the SDO?
Implementation Guide
Not required.
E) Is there only one implementation guideline (or are there
major options that impact compatibility)?
Conformance Standard Specification
Since this is a guideline, conformance testing is not applicable
F) Is a conformance standard specified?
G) Are conformance test tools available?
H) Source of test tools?
I) If the standard is under development, what parts of it
are ready now?
Development Stage
CPR Project Scenarios is final and was released in April 1996.
J) What extensions are now under development?
Extensions
CPR Project Scenarios may be expanded as further examples of uses are developed.
K) What are the major milestones toward standards
completion?
L) What are the projected dates for final ballotting and/or
implementation?
M) Please note any other indicators of readiness that may
be appropriate.
VIII. Indicator of Market Acceptance
Notes: A) If the standard is a guideline, how many copies have been
requested and distributed?
Market Acceptance
No information is available about sales of this relatively new product.
B) If the standard is an implementable standard, how many
vendors, healthcare organizations and/or government
agencies are using it?
C) Is this standard being used in other countries (which
are they)?
D) Please note any other relevant indicator of market
acceptance within the public or private sector.
IX. Level of Specificity
Notes: A) If your standard is a guideline, how detailed is it?
B) If it is an implementable standard, describe how
detailed its framework is and its level of granularity.
C) Does the standard(s) reference or assume other standards
to achieve more specificity?
D) If it includes or assumes code sets, which ones are they?
E) What is the description of the code set?
F) How is the code set acquired?
G) Is there a users' guide or some other assistance
available on the code set?
H) If the code set is currently in use, what is the extent
of its use (e.g., approximate number of users)?
I) If the code set is under development, what are the
projected dates of completion and implementation?
X. Relationships with other standards
Notes: A) Identify other standards and the relationship(s) with
other standards such as inclusion, dependency, interface
overlap, conflict or coordination.
B) Identify specific standards reconciliation or
coordination activities.
C) What portion of the specification and functionality is
affected by this coordination?
D) What conditions are assumed in order for this
coordination to be effective?
E) Is this standard consistent with international standards?
If so, which standards?
F) What gaps remain among related standards that should be
addressed?
G) Describe what is being done to address these gaps.
XI. Identifiable Costs
Notes: A) Please indicate the cost or your best estimate for the
following:
Cost
CPR Project Scenarios is available from CPRI at a cost of $25.
- Cost/timeframes for education and training
III. ANSI Accreditation
The Patient Core Data Set development organization is not ANSI accredited. PCDS development is complete and future efforts include seeking national acceptance and accreditation.
IV. Name of Standard:
Patient Core Data Set
V. Contact for more information:
Alice Renner
Wright State University
College of Nursing and health
3640 Colonel Glenn Highway
Dayton, OH 45435
Phone: 937-775-2591
Fax: 937-775-4571
E-mail: arenner@wright.edu
VI. Description of Standard:
Through support of the Agency of Health Care Policy and Research, Public Health Service, Blue Chip Computers Company in collaboration with Wright State University-Miami Valley College of Nursing and Health completed SBIR research for a comprehensive design of an Integrated Patient Information System (IPIS). [ Blue Chip Computers Company, Inc., Integrated Patient Information System, SBIR Grant, Contract Number 282-94-2039, Funded by DHHS Public Health Service, Agency for Health Care Policy and Research] Research findings confirmed the hypothesis that the inadequacy of current patient information systems can be attributed to the following fundamental causes: (1) The lack of uniform standards of patient minimum data sets; (2) The lack of systems interoperability and overall data integration in existing patient information systems; and (3) The lack of continuity of the patient health records and data exchange capability. The Wright State University consultants undertook the development of a Patient Core Data Set (PCDS) in response to the lack of uniform standards of minimum data sets and lack of standards in data transfer for continuity of care. The PCDS consists of a common core of data elements to be collected for all patients receiving health care. The PCDS provides the uniform standard of electronic patient data exchange among different health care institutions needed by a variety of users through compatibility with HL7 and ASTM electronic data interchange standards. The ability to exchange patient data accurately and timely can eliminate unnecessary duplication of tests, diagnoses and treatments.
(a) Objectives - The objectives of the Patient Core Data Set are to provide for the development of a longitudinal record of a patient's health and medical history through the use of a common set of 50 standard data elements with uniform definitions, and coding consistent with ASTM and HL7 standards. The data elements are divided into three areas: patient identification, service, and health.
The goal of the PCDS is to provide for a longitudinal record of a patient's health and medical history by making access to data from each health care episode easily accessible. Ideally following an episode, the core data set would be transferred to the patient's primary practitioner's office for updating the patient's record and/or to a regional or state data repository. However, until this becomes a reality, the PCDS residing in any facility could be easily queried upon request from another facility and because of the standardization could be expediently transferred from facility to facility.
(b) Function - The PCDS is essential information for a variety of health professionals, including clinicians, administrators, researchers, and policy makers. It is intended for transfer across all patient-care settings. As a core data set, the PCDS is not designed to be sufficient to meet the total data needs of any one user group. It is, however, recommended for inclusion in all computer-based patient records. All elements of the PCDS must be present to describe patient care across settings.
(c) User environment - The transfer of PCDS information allows comparability of patient data across clinical populations, health-care settings, and local, state and national regions. The PCDS is intended for outcome studies of health care effectiveness and clinical practice guideline usage. For example, clinical practice could be guided by information obtained from analysis of the effectiveness of a specific treatment modality. Patterns of service utilization and resource allocation can be investigated by health-care administrators. Furthermore, aggregate data collected on health risks and life-style behaviors have the potential to influence health policy decision making. Additional pieces of information may be needed beyond the PCDS by the various users, but should be obtained from the complete computerized patient medical record.
(d) Systems environment - This standard may be used from any operating system, network or hardware platform.
(e) Application function/domain completeness - The elements within the data set are complete.
(f) In what way(s) is this standard superior to other standards in this category/classification? - The PCDS is the only completed data set to date that incorporates the concept of "core data" for all patients across all health care settings. Core data is defined as data that meets the essential needs of multiple users, that is transferred across all patient-care settings, and that provides for continuity of care by forming the basis of a patient's computerized longitudinal medical record. Although various health constituencies have developed their own uniform data sets, these sets exist in isolation as each set has been created for specific purposes of the constituency that developed it. PCDS allows comparability of patient data across clinical populations, healthcare settings, and local, state and national regions. PCDS provides guidelines for both the user and the programmer. and includes the following information for each data element: name, number, definition, data uses, discussion, data type and field length, repetition, coding scheme, and relevant data standards and guidelines. The research team made a concerted effort to incorporate standards for computerized patient records in the PCDS and to make it compatible with HL7 and ASTM electronic data interchange standards. Future research efforts include mapping the PCDS data elements to elements in other common data sets, and revision over time based on field testing, other pertinent research, and developments in the field of health care data standards.
Readiness of Standard:
(a) Is it a guideline? - PCDS is a standard for building the longitudinal computerized patient record. The PCDS contains 50 data elements in three categories: patient identification, service, and health. PCDS includes the following information for each data element: name, number, definition, data uses, discussion, data type and maximum field length, repetition, coding scheme, and relevant data standards and guidelines. The exchange of information supports administration, clinical practice, research, and health policy making.
(b) Is it implementable? - The PCDS has been implemented in an integrated patient information system developed for a prenatal clinic and labor and delivery unit of a hospital.
(c) How can the standard be obtained? The standard can be obtained by contacting:
Alice Renner
Wright State University
College of Nursing and Health
3640 Colonel Glenn Highway
Dayton, OH 45435
Phone: (937) 775-2591
Fax: (937) 775-4571
E-mail:arenner@wright.edu
(d-e) Does it require a separate implementation guide? - The data set does not require a separate implementation guide a copy of the PCDS provides information on implementation with each element. PCDS provides guidelines for both the user and the programmer and includes the following information for each data element: name, number, definition, data uses, discussion, data type and field length, repetition, coding scheme, and relevant data standards and guidelines.
(f) Is a conformance standard specified? - The PCDS specifies conformity, but recognizing that conformity will only come with a federal mandate, provides for alternate coding systems to be identified in the data exchange between computer systems. Standardization is more easily accomplished in the areas of patient identification and service elements, than in the clinical data area. Reporting of patient identification and service elements have been mandated for reporting for Medicare and Medicaid reimbursement since the 1980s, resulting in a degree of standardization. Clinical data, however, has been the last data to be computerized by healthcare facilities and much clinical data is still relegated to the paper record.
(g-h)Source of test tools?- None available to date.
(I) If the standard is under development, what parts of it are ready now? - The entire data set is available for use.
(j) What extensions are now under development? - Research continues on the relevance of each data element to the concept of "core data." The data set is dynamic and revision will be based on further national input and field testing which will result in additions or deletions of elements, or specificity of detail of an element. Other pertinent research and developments in the field of health care data standards will impact the PCDS.
(k) What are the major milestones towards standards completion?- The following are major activities in the research and development of the PCDS toward making it ready for consideration as a standard:
The development team researched and evaluated existing health care data sets and used this as a basis for forming the PCDS. During development of the PCDS, a content validity survey was conducted to obtain both local and national input on the data set, evaluate the relevance of the elements to the data set and obtain recommendations for additions and changes to the data set. The evaluation tool that was used is based on the article: Lynn, M.R. (1986) Determination and quantification of content validity. Nursing Research. 35(6), 382-385. The tool provides determination of the content representativeness or content relevance by the application of a two-stage (development or judgment) process. Quantification of content validity is achieved through the use of the index of content validity (CVI) which is determined from the ratings of the relevance of the data elements using a 4-point ordinal rating scale. The content validity surveys provided much valuable information for the development of the data set.
Because the data set had to be useful to a variety of users including administrators, clinicians, researchers, and health policy makers, the consultants sought experts from these areas with proficiency in health care informatics. Fourteen national experts participated in the workgroup sessions held June 27-29, 1996. The experts included the Executive Director of the Medical Records Institute and chair of the national committees: ASTM E31.20, Standards Committee on Electronic Signatures in Health Care and the American National Standards Institute – Task Force on International Cooperation; the chairman of ASTM E31 Healthcare Informatics; the chair of ASTM E31.12 Computer-Based Records committee; the chair of Health Level 7; an expert and consultant on the Long Term/Home Health Delivery System and author of the Saba Home Health Care Classification System, nurse researchers involved in standards development for nursing data elements for nursing interventions and outcomes; representatives form the Agency for Health Care Policy and Research; the Joint Commission on Accreditation of Healthcare Organizations; experts in outcomes research, a developer of an enterprise computer system for several hospitals and clinics; and health policy researchers.
The Wright State consultants are also investigating the formation of an American Society for Testing and Materials (ASTM) committee for the PCDS similar to the committee for the computerized patient record. The data set was developed to be compatible with the E31 Health Informatics standards and these standards are referenced in the data set.
Because the HL7 has become the defacto standard for data exchange in health care informatics, compatibility with Health Level 7 (HL7) protocol for health information exchange was also important in the development of the PCDS. The consultants plan future work with HL7 experts to identify the corresponding HL7 segment data fields with the PCDS data fields. Inclusion of the information on coding according to the standards for data interchange will help acceptance and use of the data set.
What are the projected dates for final balloting and/or implementing?
N/A
Indicator of Market Acceptance:
The data set development has just been completed and the set has been included in a report to the Agency for Healthcare Policy and Research. The PCDS has not been made distributed to date.
Level of Specificity:
(a) How detailed is your standard? - The PCDS has been developed to meet specific needs of a variety of health care professionals including clinicians, administrators, researchers, and health policy makers.
(b) How detailed is the framework and its level of granularity? - A separate implementation guide is not available at this time. Each data element is described in detail with a discussion of the conceptual basis or any other specific aspects of data collection not covered in the documentation for that element. The level of detail of the clinical elements in particular may be increased in future revisions of the data set if additional testing indicates that the detail is not sufficient to meet the crucial needs of clinicians.
(c) Does the standard reference or assume other standards to achieve specificity? -
The PCDS does reference other standards to achieve specificity. It is compatible with and references ASTM and Health Level 7 protocol standards for data transmission of information collected for the data set.
(d-h) If it includes or assumes code sets, which ones are they and how are the code sets acquired? - The PCDS uses the following code sets:
CODE SETS |
ACQUIRED FROM |
|
Health Care Procedure Codes (HCPCS) |
HCFA |
|
ICD-9-CM Procedure Codes |
National Center for Health Statistics |
|
CPT Codes - Physicians Current Procedure Terminology |
American Medical Association |
|
Patient Identification/Occurrence Codes |
National Uniform Billing Committee |
|
Health Level 7 |
Health Level Seven |
|
Logical Observation Identifier Names and Codes (LOINC) |
Duke University |
|
ASTM E1238-94 and E1384-96 |
American Society for Testing Materials |
|
National Drug Code |
|
|
World Health Organization Drug Records |
World Health Organization |
|
North American Nursing Diagnosis Association (NANDA) |
North American Nursing Diagnosis Association |
|
Nursing Intervention Classification System |
University of Iowa (Mosby Publishing Co.) |
|
Nursing Outcomes Classification System |
University of Iowa |
|
National Provider Identification File |
HCFA |
|
Systematized Nomenclature of Medicine (SNOMED) |
College of American Pathology |
X. Relationships with other standards
(a-c) Identify other standards and the relationships with other standards:- The standards that have been referenced in the PCDS are as follows:
ASTM 1238-94
ASTM 1384-96
Health Level 7
The coding of the data elements in the PCDS and suggested format for electronic exchange of the information are consistent with these standards.
Identifiable Costs:
(a) Cost of licensure - No license is necessary at this time to use the PCDS
(b) Cost of acquisition - The cost of reproducing the data set and distribution costs have not been determined yet, but should be minimal.
(c) Cost/timeframes for education and training - The cost/timeframe for education and training will depend upon the individuals and the skill levels of the individuals. The coding of the database is discussed in the data set and only the most widely used code sets have been incorporated in the data set
(d) Cost and timeframes for implementation - The cost/timeframe for implementation depends upon the systems capability, hardware platform, and internal resources available for implementation.
Standard Specification for Defining and Sharing Modular Health Knowledge Bases (Arden Syntax for Medical Logic Systems)
V. Contact for more information
Terry Luthy
American Society for Testing and Materials (ASTM)
100 Barr Harbor Drive
West Conshohocken, PA 19428-2959
phone: (610)832-9500
fax: (610)832-9666
email: tluthy@mail.astm.org
Harm Scherpbier, MD
Chairman ASTM E31.15
SMS
51 Valley Stream Parkway
Malvern PA 19355
phone (610)219-4762
fax: (610)219-3124
email: harm.scherpbier@smed.com
VI. Description of Standard
Notes:
A. Include separate statements for:
clinical and/or other functional areas)
- systems environment (operating systems, network,
hardware or other requirements)
- Application function/domain completeness (Within the
defined scope of this standard, what functions/codes
are complete?
- In what way(s) is this standard superior to other
standards in this category/classification?
- any other relevant characteristics
Objectives: promote and facilitate the sharing of medical logic in the form of Medical Logic Modules. A Medical Logic Module contains sufficient knowledge to make a single decision. Contraindication alerts, management suggestions, data interpretations, treatment protocols, and diagnosis scores are examples of health knowledge that can be represented using MLMs.
Using the Arden Syntax, health providers and health delivery systems can share MLMs, independent of the clinical information system at their site.
Functions: The Arden Syntax is a standard syntax to represent MLMs. Each MLM contains administrative information about the author of the MLM, library information about the purpose of the MLM with links to medical reference literature, and a knowledge section containing the knowledge in a standard language. The knowledge section contains the data needed from a clinical information system to process the MLM, the trigger event causing the MLM to execute, the logic, and the action to be taken if the MLM needs to alert a clinician about a patient situation.
User Environment: primarily clinical, also administrative and research.
Systems Environment: the Arden Syntax is independent of the systems environment. Implementations exist on mainframes, PCs, client/server systems, etc.
Application function/domain completeness: the Arden Syntax 92 version is complete. Future extensions include further standardization of the data needed to process an MLM, which is dependent on other standardization efforts in clinical data modeling and vocabularies (outside the scope of this standard). Other areas of knowledge representation will be included in future versions.
In what way is standard superior to other standards in this category: There are no other standards in this category.
VII. Readiness of Standard
Notes:
A. Is it a guideline? If so, does it address policy, process, practice or design?
It is an official standard.
B. Is it implementable? (If so, is it fully or partially implementable?,explain)
Several implementations exist, both in academia as well as by commercial clinical software vendors. The standard is both fully as well as partially (or incrementally) implementable. In other words, some developers choose to implement the entire Arden Syntax at once, others choose to start with commonly userd Syntax functions, adding others later (incrementally).
A. How can the standard be obtained?
Order from ASTM (address and phone see above).
D. Does it require a separate implementation guide? (If so is the guide approved by the SDO?
No.
E. Is there only one implementation guideline (or are there major options that impact compatibility)? N/A
A. Is a conformance standard specified?
Not at this time.
A. Are conformance test tools available?
Not at this time.
A. Source of test tools?
Several commercial syntax checkers are available.
I. If the standard is under development, what parts of it are ready now?
N/A - Standard has a complete 1992 version.
A. What extensions are now under development?
See above:
A. What are the major milestones toward standards completion?
N/A
L. What are the projected dates for final ballotting and/or
implementation? N/A
M. Please note any other indicators of readiness that may be appropriate.
VIII. Indicator of Market Acceptance
Notes:
A. If the standard is a guideline, how many copies have been requested and distributed?
B. If the standard is an implementable standard, how many vendors, healthcare organizations and/or government agencies are using it?
Academic institutions: approx. 7 that I'm aware of (both US and international), probably others that I'm not aware of.
Commercial software vendors: >6, including most large clinical information systems vendors, either have products on the market today or to be released 1997.
A. Is this standard being used in other countries (which are they)?
Sweden, UK, Germany. Possibly others that I'm not aware of.
D. Please note any other relevant indicator of market acceptance within
the public or private sector.
IX. Level of Specificity
Notes:
A. If your standard is a guideline, how detailed is it?
Very strictly defined syntax.
B. If it is an implementable standard, describe how detailed its
framework is and its level of granularity.
Fully defined syntax for writing clinical logic. Only exception of tight definition: the definition of the data needed in an MLM is not standardized. The syntax allows local implementors to use any query language and vocabulary to retrieve the data needed in an MLM. This allows the current Arden Syntax to be used in very diverse clinical information environments. Work is in process to tighten the definition of data, but this is a long term process.
C. Does the standard(s) reference or assume other standards to achieve
more specificity? No.
A. If it includes or assumes code sets, which ones are they? N/A
E. What is the description of the code set?
F. How is the code set acquired?
G. Is there a users' guide or some other assistance available on the
code set?
H. If the code set is currently in use, what is the extent of its use
(e.g., approximate number of users)?
I. If the code set is under development, what are the projected dates
of completion and implementation?
X. Relationships with other standards
A. Identify other standards and the relationship(s) with other standards such as inclusion, dependency, interface overlap, conflict or coordination.
Currently: no dependencies
B. Identify specific standards reconciliation or coordination activities.
Future activities to further specify the data definitions: work with standards organizations to provide clinical data model ( for example HL7), query language, and vocabularies (for example LOINC, SNOMED, ICD9, etc.).
C. What portion of the specification and functionality is affected by this coordination?
The data slot - the slot where needed data are specified.
Standard is available to international users, and is currently used by international organizations.
A. What gaps remain among related standards that should be addressed?
Clinical data model: no complete clinical data model exists today.
Vocabularies: various vocabularies exist, some overlapping. For the Arden Syntax to work optimally, there needs to be a single, complete, non-overlapping standard for each vocabulary domain, for example one vocabulary for lab results, one for medications, etc.. The coordination and creation of these vocabularies is outside of the Arden Syntax scope. We rely on other SDOs to create these vocabularies.
XI. Identifiable Costs
Notes:
A. Please indicate the cost or your best estimate for the following:
License cost: none
Acquisition cost - depends on number of copies. Single copy approx. $32.00, discount on larger quantities.
Cost/ timeframes for education, training, and implementation: different for each organization.