Re: Dumb standards questions

[Rubin, Ken]

Let me take a hack at this.  For the GCPR activity, a significant amount
of time was spent looking at multiple models (including HL7, CEN TC251
EHCR, etc.).  To make a long story short, below is segment from a
spin-off white-paper describing a means to understand and differentiate
these models, along with an instance 'matrix' containing many of these
models and how they interrelate.

The matrix attached is the instance example with the healthcare models
most often discussed on this thread.  The columns in the matrix are
based in the ISO Reference Model for Open Distributed Processing
(RM-ODP).  If you are interested in clarification or more detail, drop
me a note and I'll send you the whitepaper.  I hope this is useful.

- Ken


Brian Bray wrote:

> I have a couple of standards questions that I'm hoping the group can
> help me with.
>
> What's the relationship between CEN-TC251 and HL7 ?
>
> Anyone heard of SWNEX ?
>
> -Brian

--
**********************************************************************
Kenneth S. Rubin
EDS / VHA IT Architecture Account
[EMAIL PROTECTED]  (e-mail)     703-845-3827 (voice)

5113 Leesburg Pike
Skyline 4 Suite 800
Falls Church, Virginia 22041

Title: Healthcare Standards Roadmap Matrix v2

Healthcare Standards Roadmap Matrix v2.0 Viewpoint Enterprise Technology Information Computational Engineering Description Formalized scope, business purpose, policies, impacts of the system. Includes the roles played, activities under-taken, and policy statements about the system. Choices of specific HW, SW, constraints to assure compliance with other viewpoints; identification of conformance points, implicit or explicit, resulting from technical choices Defines the information and relationships, information semantics, and information processing requirements of the system. Includes static, dynamic, and invariant schemas. Structures, concepts, interaction rules, for the specification + functional decomposition into objects. Includes bindings, interface specifications, environment contract behavior, and transparencies. The expression of the way [object] inter-action is achieved and the resources needed to do so: primarily the support of the interactions between computational objects. Business Functional Context Granular (content) Identification of those components of the healthcare domain impacting information interchange and interoperability Not proscribed so as to be able to support a multiplicity of technologies and paradigms. -FAM-D -HL7 RIM -HL7 USAM -Canadian Health Data Model -Australian NHIM -POMA -UK NHS HcM -HL7 Use Cases -COSMOS Model -FAM-A Modeling Formalizations UML, USDP products Abstract (form) Representation of highly-granular components capable of encapsulating, transporting, and/or representing the content of information models Should be suitable for a variety of technologies: in particular message-oriented middleware and distributed object technologies. -HL7 PRA Metamodel -CEN TC-251 EHCR PRA -GCPR PRA Model -HL7 Clinical Template Mdls -GEHR Archetypes ISO 11179 Compliant Metadata -HL7 Clinical Templates -HL7 XML PRA Service Context Common services Supporting the Reference Domain Specification. Technological paradigm in which the services are to be implemented (e.g., messages, distributed objects, etc.) -CORBAmed Info Models -CCOW Standard -GEHR Object Model -GEHR Object Model -CORBAmed (Signatures, mandatory/optional requirements) Normative Interface Definitions (IDL) Implementation Context <subtype as needed> Requirements, scope, and objectives of an implementation. Technology instances on which the implementation is to be based (e.g., COTS products, platform, etc.)   Logical Database Design HL7 RMIMs Service Design Specifications (e.g., CORBAmed services) VHA Data Registry Design HL7 MDF GEHR Kernel HL7 2.x messages HL7 3.x messages CORBAmed Services GCPR Framework CCOW Implementations Space RM-ODP Viewpoints   Documentation of the problem space, domain of interest, functional requirements etc. 2.Artifacts, products, etc. with the objective of identifying, describing, and/or relating business functional components at a granular level. 3 Artifacts, products, etc. with the objective of identification of abstractions, meta-models, etc. (e.g., generalization of the granular models, templates defining structure of granular models, "containers" capable of transporting details, etc. The component services required to support needs/content as identified by the business functional context, (or services implicit in supporting and/or managing that content). Work products developed with the intention of building implementable systems. Draws from other contexts as scoped to address requirements for a targeted implementation