Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Document meta-data

o    Title SHALL   match the official HL7 name for publication including:

  • Base version is specified

§  Any pre-adoption or post-adoption is clearly outlined

  • Realm is specified
  • Document type (STU, Normative, etc)

o    Publication date SHALL BE  specified

o    Title page SHALL BE   the official HL7 title page including official copyright text

o    Where appropriate, terminology text is included

o    Table of contents SHALL exists include lists of tables and figures (note that message, segment, data type and value set "tables" do not need to be explicitly listed in the TOC)

o    Authors and contributors SHALL be  listed

  • Context

o    Purpose and audience of the document SHALL BE described

o    Scope (both in and out of scope) of the document SHALL be clearly defined

  • Use Cases

o    At least one use case SHALL be  described

  • Note that technical requirements that are not required for the IG use case(s) should not be required by the document
  • Use cases SHALL include

§  Actors

§  User story

§  Message flows including a list of message profiles used to fulfill the use case

§  Acknowledgement choreography

  • Technical requirements

o    General

  • Conformance statements SHALL BE  machine testable
  • Each conformance statement SHALL have a unique ID

§  Conformance statement IDs need not be meaningful or in alphabetical/numeric order

§  Conformance statement IDs SHALL NOT  be reused within the document or between releases of the same IG

§  Conformance statement IDs SHOULD be consistent between releases of the IG

  • Conformance statements MAY  be reused within a document if the requirement applied to multiple locations in the message

§  For example, if a conformance statement applies to a field in the OBX segment following both a PID and an OBR segment, then the conformance statement can be reused in both locations

  • An IG SHALL NOT  use z-segments or custom data types (note that a constraint of a base data type is not a "custom data type")

o    Messages

  • Each message SHALL  be associated with a Profile ID for use in MSH-21
  • Each message SHOULD include a narrative description regarding the role of the message in one or more use cases
  • Segments and Segment Groups in the message SHALL have a Usage and a Cardinality
  • Segments with a Usage of R, RE or C SHOULD point to a constrained description of the segment elsewhere in the document

§  The exception to this is where a segment is required within an optional segment group (eg the Patient_Visit segment group is optional, but if included, the PV1 segment is required - in this case, the required PV1 segment does not need to be described in the document (it just defaults to the based standard definition)

o    Segments

  • Fields in the message SHALL have a Usage and Cardinality
  • Fields with a Usage of R, RE or C SHOULD point to a constrained description of the field data type elsewhere in the document
  • Fields with a coded data type (CWE, CNE, ID, IS, etc) should SHALL  be bound to a value set described elsewhere in the document

o    Data type

  • Where possible, standardized data type flavors SHOULD be use (see data type flavor project)

o    Value sets

  • Standard text describing the use and construction of value sets SHOULD be included

§  We'd need to develop this (possibly starting with NIST text or text in the immunization IG)

  • Each value set SHOULD have an OID
  • Each value set SHOULD be declared as open or closed and static or dynamic

§  We'll need to provide a reference to definitions for these attributes

  • Each value in a value set SHOULD include Usage

§  Values should only be required when they are critical to the fulfilment of one or more use cases

  • Only value sets which are bound to a field, data type or co-constraint SHALL be included in the IG
  • Should value sets have gone through the harmonization process?

§  Need to talk to Vocab about this

  • Examples

o    Each use case SHALL  contain at least one full example message for each profile

  • Use of "message snippets" is discouraged although segments that are non-relevant for the point being made may be abbreviated in the context of a full message

o    Example messages must be prefaced with standardized text indicating that they should not be used for the purposes of coding and are only for the purposes of better understanding the requirements

 

 

Anthony (Tony) Julian FHL7,MQF|IT Technical Specialist II|EIA Platform|Information Technology|Phone: 507-293-8384|Fax: upon request|E-mail: ajulian@mayo.edu

Mayo Clinic | 200 First Street S.W. | Rochester, MN 55905 | www.mayoclinic.org

 

From: Radov, Nicholas O [mailto:nradov@uhc.com]
Sent: Friday, February 01, 2019 10:12 AM
To: Craig Newman; Julian, Anthony J.; sandra.stuart@kp.org
Cc: v2mgmtgrp@lists.hl7.org
Subject: [EXTERNAL] RE: v2 IG quality metrics

 

I agree this would be a good thing to do. The regular InM biweekly conference calls are supposed to resume on 02/14 at 3:00 PM EST, however I’ll be out at HIMSS that week. If we want to have a special call next week then best times for me would be Tuesday / Wednesday / Thursday at 10:00 AM PST or Friday at 1:00 PM PST.

 

Nick Radov | Director, Int Standards & Compliance

)+1 612-632-2612 | * nradov@uhc.com | unitedhealthgroup.com

 

Our United Culture  The way forward

UNITEDHEALTH GROUPINTEGRITYCOMPASSIONRELATIONSHIPSINNOVATIONPERFORMANCE

 

 

From: Craig Newman [mailto:Craig.Newman@altarum.org]
Sent: Friday, February 01, 2019 7:32 AM
To: Julian, Anthony J.; Radov, Nicholas O; sandra.stuart@kp.org
Cc: v2mgmtgrp@lists.hl7.org
Subject: v2 IG quality metrics

 

Tony, Nick, Sandy

 

Riki and I were talking about the new CDA IG quality project where they are updating the CDA IG quality criteria they previously put together. It reminded us that v2 IG quality criteria was something the v2MG wanted to work on with InM. Looking at the CDA criteria (and drawing on other conversations with Rob Snelick and other folks), we put together some very rough thoughts on what v2 criteria might look like (see below).

 

The v2 MG group would like to get together with InM to see if we can use this list as a starting point to publish a document for IG authors. If we want to ballot these criteria (at least as a for comment ballot) in an upcoming cycle, we would need to work on a PSS and approvals (by early April if we want to ballot in September).

 

Please let us know when would be a good time to talk. We can get v2MG folks on an InM call if you like or we can add it to a v2MG call agenda if that works better.

 

Thanks

Craig

 

  • Document meta-data

o    Title matches the official HL7 name for publication including:

  • Base version is specified

§  Any pre-adoption or post-adoption is clearly outlined

  • Realm is specified
  • Document type (STU, Normative, etc)

o    Publication date is specified

o    Title page is the official HL7 title page including official copyright text

o    Where appropriate, terminology text is included

o    Table of contents exists include lists of tables and figures (note that message, segment, data type and value set "tables" do not need to be explicitly listed)

o    Authors and contributors are listed

  • Context

o    Purpose and audience of the document are described

o    Scope (both in and out of scope) of the document is clearly defined

  • Use Cases

o    At least one use case is described

  • Note that technical requirements that are not required for the IG use case(s) should not be required by the document
  • Use cases should include

§  Actors

§  User story

§  Message flows including a list of message profiles used to fulfill the use case

  • Technical requirements

o    General

  • Conformance statements must be machine testable
  • Each conformance statement must have a unique ID

§  Conformance statement IDs need not be meaningful or in alphabetical/numeric order

§  Conformance statement IDs must not be reused within the document or between releases of the same IG

§  Conformance statement IDs should be consistent between releases of the IG

  • Conformance statements may be reused within a document if the requirement applied to multiple locations in the message

§  For example, if a conformance statement applies to a field in the OBX segment following both a PID and an OBR segment, then the conformance statement can be reused in both locations

  • An IG shall not use z-segments or custom data types (note that a constraint of a base data type is not a "custom data type")

o    Messages

  • Each message must be associated with a Profile ID for use in MSH-21
  • Each message should include a narrative description regarding the role of the message in one or more use cases
  • Segments and Segment Groups in the message must have a Usage and a Cardinality
  • Segments with a Usage of R, RE or C should point to a constrained description of the segment elsewhere in the document

§  The exception to this is where a segment is required within an optional segment group (eg the Patient_Visit segment group is optional, but if included, the PV1 segment is required - in this case, the required PV1 segment does not need to be described in the document (it just defaults to the based standard definition)

o    Segments

  • Fields in the message must have a Usage and Cardinality
  • Fields with a Usage of R, RE or C should point to a constrained description of the data type elsewhere in the document
  • Fields with a coded data type (CWE, CNE, ID, IS, etc) should be bound to a value set described elsewhere in the document

o    Data type

  • Where possible, standardized data type flavors should be use (see data type flavor project)

o    Value sets

  • Standard text describing the use and construction of value sets should be included

§  We'd need to develop this (possibly starting with NIST text or text in the immunization IG)

  • Each value set should have an OID
  • Each value set should be declared as open or closed and static or dynamic

§  We'll need to provide a reference to definitions for these attributes

  • Each value in a value set should include Usage

§  Values should only be required when they are critical to the fulfilment of one or more use cases

  • Only value sets which are bound to a field, data type or co-constraint should be included in the IG
  • Should value sets have gone through the harmonization process?

§  Need to talk to Vocab about this

  • Examples

o    Each use case must contain at least one full example message for each profile

  • Use of "message snippets" is discouraged although segments that are non-relevant for the point being made may be abbreviated in the context of a full message

o    Example messages must be prefaced with standardized text indicating that they should not be used for the purposes of coding and are only for the purposes of better understanding the requirements

 

 

 

Craig Newman
Interoperability Standards Analyst | Center for Connected Health

ALTARUM | Ann Arbor, MI

 

C 734.474.8891

@CCH_altarum | altarum.org

 


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.

  • No labels