20130910 arb minutes

ARB - Meeting (Date in Title)

Agenda

1. Call to order
2. Roll Call
3. Approval of Agenda and Minutes
4. Management
   1. Review to-do list
   2. Review/update Arb BAM task list
   3. Report from Architecture Project
5. Governance
   1. Joint review of FHIR ballot
6. Methodology
7. Other business and planning
8. Adjournment

Meeting Information

HL7 ArB Work Group Meeting Minutes Location: Telcon		Date: 20130910 Time: 5:00pm U.S. Eastern
Facilitator	Constable, Lorraine	Note taker(s)	[[User:Ajulian | Julian, Tony]}
Attendee	Name	Affiliation
X	Bond,Andy	NEHTA
X	Constable, Lorraine	Constable Consulting Inc.
.	Curry, Jane	Health Information Strategies
X	Dagnall, Bo	HP Enterprise Services
X	Hufnagel, Steve	U.S. Department of Defense, Military Health System
X	Julian, Tony	Mayo Clinic
.	Lynch, Cecil	Accenture
.	Milosevic, Zoran	Deontik Pty Ltd
R	Parker, Ron	CA Infoway
.	Quinn, John	Health Level Seven, Inc.
X	Stechishin,Andy	CANA Software and Service Ltd.
.	Guests
R	Kreisler, Austin	HL7 TSC Chair
X	Shakir, Abdul Malik	City of Hope National Medical Center
.	Laakso, Lynn	HL7
.
.	Legend
X	Present
.	Absent
R	Regrets
Quorum Requirements Met: Yes

Minutes

• Review of Minutes and Agenda
  • Motion to approve minutes (Tony/Andy s)
  • Vote (4-0-1)
• Review of todos
• FHIR ballot review
  • Bo:No evidence of binding to data modeling. Technology driven - lacks business tracability.
  • Bo:Does not describe business problem.
  • Bo:Lots of references to profiles, no definition, no profile list.
  • Bo:Some resources are atomic and reusable. Some are specific where the title limits the usage context.
  • Bo:Combination of medication and order would make a medication order.
  • AMS: Seems you have an idea what a profile is.
  • Bo:Yes.
  • AMS: No description of why it is better than V2 or V3 - instead the description of the problem space.
  • Bo: They need to define the problem.
  • Lorraine: The material is out there, but not in the standard.
  • AMS: I often answer that FHIR is well suited for the mobile environment because of its compact size and speed of extracting data.
  • Lorraine: That is one example of the problem space.
  • Bo: Fifth theme: A lot of technical assertions, but the rationale is not well expressed. It may be self-evident to the developers, but not to the reader.
  • Bo:I am sure many of these foundational decisions were the result of some debate and analysis. Would be helpful to understand the rationale for these decisions.
  • Bo: 19 Should not this be explicit in the resource itself and not just in the documentation? Decision support and computerized algorithms need to understand the scope and intent if they are expected to process the resource accurately.
  • Bo: does the is-Modifier change a specific thing, or the whole thing. Needs scope assertion.
  • AMS: Example would be nice - does it negate the data, or the data or what?
  • AMS: should introduce concept, then show example.
  • Bo:22 Is there an enumeration of “kinds of support”? Without it, this becomes hard to manage and inconsistent. How do you govern this?
  • Bo:Not sure color coding is a good approach for providing necessary detail. I thought one of the premises behind FHIR was to be tool agnostic. What if I am creating or reviewing resources in a non-WYSIWYG editor?
  • Bo:29 Issues with the choice datatype - exclusive OR in UML.
  • Lorraine: Solving as a concatenated string.
  • Bo:42:How do you ensure and govern interoperability when the spec doesn’t specify the actual bindings? This doesn’t seem workable.
  • Lorraine: How do you assert the binding in a computable manner?
  • Bo:Seems odd that resources are used both for primary content as well as for control constructs such as document and message. Shouldn’t the document or message be a profile or some type of control construct other than a resource? Otherwise, this seems to be overloading the purpose of a resource.
  • Bo: I think resources should always be usage context neutral to maximize usage content reuse. Instead, profiles are what should provide the usage context.
  • Bo:Context neutral resources can either be static (specifying content related a patient) of dynamic (specifying content related to a behavior). However, a resource should never be both static and dynamic because this implies the type of usage context that a profile should provide.
  • Bo:Some of the resources listed are context neutral and static (e.g., AdverseReaction). This is good. However, every dynamic resource shown is bound to a static concept making them context specific (e.g., MedicationAdministration). Instead, there should be a resource for Medication (static) and a resource for Administration (dynamic) and a profile that customizes Medication and Administration resources so that they can be used together for Medication Administration events.
  • Bo:This separation of concerns allows for maximal reuse. Medications are not the only things that are administered so the administration behavior should be its own resource that gets tailored by profiles for different usage contexts (medication, therapeutic agents, etc.)
  • Bo:This recommendation also applies for MedicationPrescription, MedicationDIspense, MedicationStatement, DiagnosticReport, DiagnosticOrder, ImagingStudy, DeviceObservation
  • Lorraine: That is one of the challenges of describing scope. Boundaries are fuzzy.
  • Bo: there is no framework with boundaries for how atomic or compound a resource should be.
  • AMS: As if we thought of resources as analogous to services. Maybe resources need to be classified - some are task, some are content.
  • Lorraine: there is an attempt - Clinical, workflow, infrastructure.
  • AMS: When does the element become a molecule, a compound.
  • Bo: Distinction from the model of content vs model of use.
  • AMS: Thanks to Bo - i was too lazy to read the document, but not too lazy to read your comments.
  • AndyS: Bos comments are dead-on. There are a lot of things that stick in you - profiles are big in whats happening, but no description of what they are, what they do.
  • Lorraine: Ballot content is not frozen.
  • Tony: Needs publishing infrastructure.
  • AndyS: In developing against the spec I find most of what I need, but the readability is lacking, which has value.
  • Bo: Spec does not address compositional grammer or post-coordination.
  • Lorraine: V2 ballot user defined tables: How does FHIR address?
  • Bo: Does not address early-binding vs late binding. Design binding or runtime(late) binding.
• Adjournment at 6:00pm U.S. Eastern