This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Conformance Weekly Meeting 2017 06 19"
Jump to navigation
Jump to search
(3 intermediate revisions by the same user not shown) | |||
Line 29: | Line 29: | ||
*Craig Newman | *Craig Newman | ||
*Trevor | *Trevor | ||
− | *Frank | + | *Frank Oemig |
− | *Rob | + | *Rob Snelick |
+ | *John Roberts | ||
===Discussion=== | ===Discussion=== | ||
+ | *PHER Invite: Thursday, June 29. Discussions about implementing backwards compatibility. Conformance is invited to join. | ||
+ | **Discussion is being continued from last time. | ||
+ | *Update on project proposed by Templates | ||
+ | **Waiting for PSS that Kai may have already started. | ||
+ | **Conformance to join Templates at 2pm Central meeting | ||
+ | *Birth and Fetal Death Reporting question | ||
+ | **Curly braces are an annotation {1} or just a 1 is fine in UCUM. Anything inside a curly brace should not have a semantic meaning. | ||
+ | **Still up-in-the-air on what you should do, many different options available. PHER couldn't come up with a standard. | ||
+ | **Craig can get some examples from Immunization | ||
+ | *Requiring all occurrences within a data type - question from PHER brought by Craig Newman | ||
+ | **V2 field allows multiple occurrences and there is a type that classifies it, and it has multiple required values (e.g. address might have physical and mailing) | ||
+ | **Overall consensus is, if the sender knows it then it should be sent if a required-to-support code, that seems to be a sensible answer | ||
+ | **But not sure if this is enforceable this is given the current state of how things are written | ||
+ | **Would like to see more formalism in this area | ||
+ | **Discussed footnote on Page 17 of HL7 v2.8.2 Chapter 2B that tries to refine the definition of RE. There are issues with the definition. | ||
+ | ***The conflicting definition should really be defined by a different profile | ||
+ | ***Created from conversation 6 years ago | ||
+ | **Take away: when writing 2+ chapter, need to very explicit on the expectations are for these requirements. Need to look at value sets and how they interact with field usage. | ||
+ | ***Local guides need to explicitly document their expectations. This is a stop-gap for now. | ||
+ | ***Conformance leans towards reporting all, but it should be documented so it's clear. | ||
+ | *Approve WGM | ||
+ | **Rob needs to review again | ||
+ | *Data Types | ||
+ | **Need to make sure the data types are named to not conflict with current data-types | ||
+ | **Need to discuss data type names across versions that serve the same purpose | ||
+ | **Will discuss this more on the next call |
Latest revision as of 15:02, 19 June 2017
Meeting Information
- Date: Monday, June 19, 2016
- Time: 10:00 am, North America Eastern Time (New York, GMT-04:00)
- Phone Number: +1 770-657-9270
- Pass Code: 644843
- Web Meeting: Uber Conference
Proposed Agenda Topics
- Request from Templates for new Project
- Update from John Roberts
- Birth and Fetal Death Reporting IG: Two conformance questions raised by Mead Walker on listserv (Mead Walker)
- Follow-up by Rob Snelick on research into OBX-6
- Requiring all occurrences within a data type (Craig Newman)
- Review and approve WGM minutes
- Cochair Election
- Data Types Project
- Any updates?
- Review FHIR Resource QA Tracker
- DSTU QA Guidelines
- Conformance has been asked to look at this list and see if anything needs to be added:
- FHIR Conformance Review
- First proposed topic (looking at Slide 2): Usage & Cardinality
- Original document FHIR Constraints and Rules
Attendees
- Nathan Bunker
- Craig Newman
- Trevor
- Frank Oemig
- Rob Snelick
- John Roberts
Discussion
- PHER Invite: Thursday, June 29. Discussions about implementing backwards compatibility. Conformance is invited to join.
- Discussion is being continued from last time.
- Update on project proposed by Templates
- Waiting for PSS that Kai may have already started.
- Conformance to join Templates at 2pm Central meeting
- Birth and Fetal Death Reporting question
- Curly braces are an annotation {1} or just a 1 is fine in UCUM. Anything inside a curly brace should not have a semantic meaning.
- Still up-in-the-air on what you should do, many different options available. PHER couldn't come up with a standard.
- Craig can get some examples from Immunization
- Requiring all occurrences within a data type - question from PHER brought by Craig Newman
- V2 field allows multiple occurrences and there is a type that classifies it, and it has multiple required values (e.g. address might have physical and mailing)
- Overall consensus is, if the sender knows it then it should be sent if a required-to-support code, that seems to be a sensible answer
- But not sure if this is enforceable this is given the current state of how things are written
- Would like to see more formalism in this area
- Discussed footnote on Page 17 of HL7 v2.8.2 Chapter 2B that tries to refine the definition of RE. There are issues with the definition.
- The conflicting definition should really be defined by a different profile
- Created from conversation 6 years ago
- Take away: when writing 2+ chapter, need to very explicit on the expectations are for these requirements. Need to look at value sets and how they interact with field usage.
- Local guides need to explicitly document their expectations. This is a stop-gap for now.
- Conformance leans towards reporting all, but it should be documented so it's clear.
- Approve WGM
- Rob needs to review again
- Data Types
- Need to make sure the data types are named to not conflict with current data-types
- Need to discuss data type names across versions that serve the same purpose
- Will discuss this more on the next call