1. Cologne Roundtable Discussions

2. Issue topics
When is it ok to use ‘code’ rather than CodeableConcept and required or extensible bindings?
Negatives on Observation
How “stand-alone” are resources expected to be?
Negative on FM resources
How do we get consistency in determination of isModifier?

3. Code/Coding + binding strength

4. Issue Sample ballot item: GF#16700
Issues such as Observation.status, interpretation, dataAbsentReason, referenceRange.type, referenceRange.appliesTo, Patient.gender
Concern that documents of clinical interest should not be constrained to code (which prohibits translations) and Required or Extensible bindings (which force translation)

5. Lloyd’s opinion
Object of HL7 is global interoperability when we can and when it doesn’t impose unreasonable expectations on implementers
Mapping is a “reasonable” expectation if
the number of codes is small
the value set covers the space
Value set is amenable to mapping from the common terminologies of the vast majority of implementer systems

6. Lloyd’s opinion (cont’d)
Changing from code to CodeableConcept means software can’t use enumerations
Does allow translations & original text to provide “original” codes plus free text
If required, must always have a code from the required value set though

7. Stand-alone-ness of resources

8. Issue
See GF#16939
ClaimResponse, EligibilityResponse, EnrollmentResponse, AppointmentResponse cannot stand alone (need Claim, EligibilityRequest, etc. to make sense)
Equivalent to an Observation that says “value was 100 mmol/L, see Order 123 for more”
QuestionnaireResponse is more stand-alone, but could be argued is not “fully” computable independent of Questionnaire

9. Issue continued Current models dictate the business model: This means:
A request must exist before the ‘event’ can exist
Information is intended to be communicated principally to the system that made the request
This means:
Can’t initiate an appointment by saying “I’d like an appointment, here’s my availability”
Can’t initiate an eligibility check, pre-authorization, without an electronic request, etc.
Can’t send results of eligibility, pre-authorization, etc. to downstream systems without also sending request

10. Resources should be context-independent
Extensibility mechanism doesn’t accommodate “workflows” outside the 80%, only “elements” outside the 80%
Therefore need to try to be workflow-agnostic, even if certain workflows are typical
At the same time, initial versions of a resource may focus on what’s known
What FMM level constraints should there be for non-workflow-independent resources?

11. isModifier

12. Issue Lots of people don’t know how to populate isModifier
In some cases, whether something is a modifier is context-specific
Depends on how people interpret the resource by default