- 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.
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).
Describe the target audience for the document.
Scope of Work
Describes what is in an out of scope for the guide.
Explains Meaning of key words and other conventions or structures used in the document.
Describe how the document is organized.
Acknowledges contributions and sponsors of the work.
This section should provide a more detailed discussion of the IG. This should contain more detailed information from the PSS.
Describe the devices, systems, components, et cetera, in reader friendly terms that describes the eco-system which this guide is meant to serve.
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.
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.
What has to be true before this use case is acted on.
The steps the user and systems goes through to enact it.
- The <user> tells <system> to <action>
- The <system> tells other <system> to <action>
- et cetera.
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
Describe the role of different actors in the above use cases (e.g., Device, App, Aggregator)
Health Data Repository
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.
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.
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
Supplemental material (if any).
|Table of Contents|