This wiki has undergone a migration to Confluence found Here
Conformance Weekly Meeting 2017 06 19
Jump to navigation
Jump to search
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