Notes from MeetingRe: [ihc] IHC TC Meeting

[Rex Brooks <rexb@starbourne.com>]

Title: Notes from MeetingRe: [ihc] IHC TC Meeting

Hi All,

The points I made in the meeting today concerned to two areas: requirements and scope.

In terms of requirements there are two areas which usually are represented in the specifications I have worked on:

• Design Requirements-requirements for the way the specification is structured, e.g. it is aimed to supply formats for a set of messages related to emergencies, web services, business processes, etc;
• Requirements for Specific Features-requirements for senders of messages, recipients of messages, types information elements such as schedules using datetime stamps, specific term-datatype definitions, etc.

Requirements are often expressed as having been derived from specific use-cases contained in separate reference documents.

In our case here, we can probably pull out requirements from the referenced materials, but it seems unlikely that we can pull out use-cases, so we should either explicitly state this or develop our own use cases, but I don't think that is wise because I think we fall into some logical conundrums if we try to reverse engineer use cases from requirements. In the other committees in which I have worked, we usually try to get domain subject matter experts to develop the use cases and requirements.

In terms of scope, it is my experience that we have had better success when we carefully define the scope before finding experts and developing requirements, but in this case we can't do that. So I think it might be best to define scope in terms of two areas:

• Local-jurisdictional (e.g. municipal, county, borough, parish), regional (e.g. RHIOs, southwest Missouri, Eastern Ohio, etc), State or Province (e.g. California, New Hampshire, etc), national and international;
• Health of Populations v. Health of Jurisdictionally-Defined Healthcare Systems.

I think we need to consider that the more broad we make our scope, the less accurate and actionable will our data and decision support capabilitiies be. It might be worth breaking up the work into a set of specifications which can then drill down to more accurate, smaller grandularities of information which will be more computationally useful.

I also think we need to consider breaking the work into two functionally distinct and separate domains: for the measurement (even if it includes self-descriptions which must be weighted accordingly) of the relative health of populations; and for the measurement of the effectiveness of the healthcare systems. I think that measurements from one functional area will be on the other, but to achieve sufficiently accurate measurements we need to avoid the effects of as much subjective reporting as we can within reason, given that some self-reporting for both functional areas is unavoidable.

Specifically I would rework sections 1 & 2:  1. Introduction; 1.1 Purpose; 1.2 History; 1.3 Structure and Scope; 1.4 Terminology; 1.5 Non-normative References; 1.6 Normative References; 2. Functional Requirements (and Use-Cases if included); 2.1 Requirements for Determining Healh of Populations; 2.2 Requirements for Determining Effectiveness of Healthcare Systems; 3. Design Principles and Concepts (Non-normative); 2.1 Requirements for Design;

That would make 3. Terms and Definitions. (I would, at least, consider making this a data dictionary.

Cheers,

Rex

At 12:44 PM -0700 6/6/07, Brett Trusko wrote:

> Hi All,
>
> This is the reminder e-mail I forgot for the last meeting.
>
> We will be discussing the attached Health Indicator standard tomorrow
> at 8:00 AM pacific on telephone line  (563) 843-5600 - Access
> Code: 652872#.
>
> Once we get this standard rolling we should have lots of fun with it.
> I have already placed it inside the WHO for review and comment.
>
> Best,
>
> Brett

Content-Type: application/octet-stream;
x-mac-type=5738424E;
    x-unix-mode=0644;
       x-mac-creator=4D535744;
name=OASIS HI Standard V05.doc
Content-Disposition: attachment;
  filename="OASIS HI Standard V05.doc"

>
> Attachment converted: Macintosh HD:OASIS
> HI Standard V05 1.doc (W8BN/MSWD) (002B30E3)

-- 

Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670