Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This is the content outline for the MH ADE Implementation Guide.  It is a work in progress.

Introduction

This section should contain the information people need to read to understand the guide.

Project Purpose and Goals

Explains the purpose of the implementation guide and its goals.  Some of the material in this section should be aligned with the Project Scope Statement (PSS).

Target Audience

Describe the target audience for the document.

Scope of Work

Describes what is in an out of scope for the guide.

Document Conventions

Explains Meaning of key words and other conventions or structures used in the document.

Document Organization

Describe how the document is organized.

Acknowledgements

Acknowledges contributions and sponsors of the work.

Overview

This section should provide a more detailed discussion of the IG.  This should contain more detailed information from the PSS.

Technical Environment

Describe the devices, systems, components, et cetera, in reader friendly terms that describes the eco-system which this guide is meant to serve.

Approach

Describe the approach used to develop functional requirements, active principles used for decision making, et cetera.

Principles to consider: Postel's Law (be forgiving in what you receive, but strict in what you send).

Using this Guide

Instructions for implementers, assessors and users on how to use this guide.  

For Implementors

For Assessors

For Users

Use Cases

Include an introductory paragraph for this section: "These are high level use cases to demonstrate the kinds of exchange that this implementation guide is meant to enable." ...

Capturing Routine Weight Measurement

General Description of what the users are trying to accomplish.

Preconditions

What has to be true before this use case is acted on.

Steps

The steps the user and systems goes through to enact it.

  1. The <user> tells <system> to <action>
  2. The <system> tells other <system> to <action>
  3. et cetera.

Post-Conditions

The net effect of implementing the use case (e.g., the outcomes)

Communicating Vital Signs, including Blood Pressure (e.g., AMA Use Case)

Glucose Monitoring (w/ manual Insulin Dose reporting)

Recording Physical Activity

Actors

Describe the role of different actors in the above use cases (e.g., Device, App, Aggregator)

Device

App

Health Data Repository

Patient/Subject

Caregiver/Healthcare Provider

Conformance

Describe how conformance to this IG can be claimed and should be assessed.

Thoughts on this topic:

Conformity assessment should be readily reproducible across different assessors.  It should be measurable against each requirement, as well as groups of requirements in a functional area.  Some IETF specifications (known as Requests for Comments or RFC) have distinguished between conforming (implements all SHALL requirements) and fully conforming (implements all SHALL and SHOULD requirements).  The distinction is useful, but the terminology used is subtle and may not be easily understood for users not familiar with this usage (it shows up in a few commonly used RFCs, but is not common, and the distinction would lost on those not familiar with standards conformity assessment in general).

A more user friendly rating system might be on an ordinal scale of 1 to 5, where 0 stars is fully non-conforming, 3 stars meets all required criteria, 4 meets all required criteria and some degree of additional recommended criteria, and 5 stars meets all required criteria, and a larger degree of recommended criteria.

For example:

0 stars: The device or system under test (SUT) does not meet any SHALL or SHOULD criteria.

1 star: The SUT meets some (but not most) of the SHALL criteria.

2 stars: The SUT meets most of the SHALL criteria.

3 stars: The SUT meets all of the SHALL criteria.

4 stars: The SUT meets all of the SHALL criteria, and some (but not most) of the SHOULD criteria.

5 stars: The SUT meets all of the SHALL criteria and most or all of the SHOULD criteria.

Functional Requirements

This is where we put SHALL/SHALL NOT, SHOULD/SHOULD NOT statements.

Q: Do we address MAY/NEED NOT? Keith believes these are clarifying, rather than evaluating.

Scenario or Category 1

Scenario or Category 2

FHIR Resource Profiles

Patient

Practitioner

Organization

Location

Observation

Device

Condition

Appendices

Supplemental material (if any).

Table of Contents
outlinetrue
indent10px
stylenone