CGIT concall 20160208

Return to Conformance

Meeting Information

• Date: Monday, February 8, 2016
  • Time: 4:00 pm, North America Eastern Time (New York, GMT-04:00)
  • Phone Number: +1 770-657-9270
  • Pass Code: 644843
  • Web Meeting: https://global.gotomeeting.com/join/647877325

Proposed Agenda Topics

• Data types - Craig Newman
• Handling Profiles - Mead Walker

Meeting Minutes

Attendees

• Nathan Bunker
• Craig Newman
• Rob Snelick
• Frank Oemig
• Mead Walker
• Ioana Singureanu

Background material

Email from Craig Newman 2016-02-08

I know at one point in the past, we agreed that harmonizing data type flavors across all HL7 V2 implementation guides would be a good thing for developers. Has a consolidated list of data type flavors been created? For the most part, I suspect the lab IGs are the primary data type flavor drivers, but I would like to harmonize the immunization flavors where possible (and add any new types we need that lab didn’t to a comprehensive list). So does such a list exist? If not, does a potential home for documenting such a list exist?

Response from Rob Snelick 2016-02-08

This is certainly something we want to do. I’d like to get these defined and include in IGAMT as “off-the-shelf” DT specializations. This is something IMO that needs to be done at the HL7 level as a formal project. Conformance and maybe InM should be the sponsors (maybe other WGs as well—e.g., OO we will certainly want to provide input). HL7 should be the source of this—IGAMT (and other tools) will be users of it. However, we can start to use IGAMT to create them to propose to HL7. The sooner, the better.

Items Discussed

• Discussing data types. Nothing formal has been done yet. Need to have some type of repository. This could be an HL7 project, so they are the source of truth. Conformance and InM should be he co-sponsors of this. As part of the project is how to go forward and publish these. Then make these known to all the HL7 v2 authors so they can use them.
  • Proposal to create HL7 project. Can use IGAMT to make list but really should go into HL7 and be tool independent.
  • Won't forbid creation of local data types, still can create new data type flavors.
  • FHIR also has a similar need for this concept. So this is a universal need. The more centralized is better.
  • In Germany they have done something like this, it's on a wiki.
  • In the US Lab space this has been done as well. It's documented within the implementation type.
  • May have different sets of flavors based on realm.
  • Easier to create yourself than have central management. But this is exactly opposite from what we need. What we have now is a mess.
  • Have to take care that creating a centralized only makes it a little harder. If done will make it easier to implement.
  • First step: Quick and dirty list of all the data types to start with? Then an HL7 project could be started.
  • RIM has a process for new proposals. Data type might need a process like this.
  • In the end, part of the project is create a repository to make them know. Eventually a v2 guide could be required to use the repository. If it's an HL7 balloted guide it's the responsibility of the author to to do this. Not initially but eventually.
  • This group can be the one who creates the flavors so it is not done in a haphazard way. We want to leverage the US Lab work. Look at naming convention used. When new ones are submitted we need to give them a method to do so. Naming convention is part of this.
  • IHE has been doing some of this already. Need to be more precise than IHE has been.
  • The idea of harmonization has some appeal. But the initial set might not be too big of a lift.
  • Motion to create project scope statement for creating a unified repository for HL7 v2 Data Type Flavors. Rob Snelick moves. Mead Walker seconds motion. 5/0/0
  • Next steps: Need a summary statement ready. InM would probably be an interested party. We should approach them. O&O and PHER would also be interested to know about it. Adding too many workgroups can add too much to the mechanics of doing stuff. Rob Snelick will take the first step in writing the summary. Nathan Bunker will put the PSS draft together. Craig Newman will start to pull data together.
• Discussion on handling profiles. Trying to create standard for US Death Reporting. Want it based on death certificate. There are a couple of data flows we are interested. Healthcare providers to state registrar, state registrar to the national center, and back from national center back to state registries. Each has different types of data. Each was originally called a profile. Then ended up working with Rob Snelick and created a series of example messages, and each was being called a profile. The question: what's a profile? There is further complication because there are also revisions and cancellations.
  • Different types of profiles and at different levels. We have specified structures that are repeated. These are repeated. Need to be able to create profiles of profiles of profiles.
  • Message profile vs an integration profile. An integration profile includes a use case.
  • Can make a general one then make a specific one. The bottom line is that you want to be able to re-use common components. Same philosophy is that using data type flavors, we can re-use the building blocks in an efficient way to create each individual profile.
  • One preferred solution is to have separate profiles but reduce documentation by only documenting the PID in one place and then reference it from all the profiles. The tooling can help by allowing deltas from a common component. Can define one PID as a core, and then have the variations off of that. Tooling can allow for change in one area and it changes in all profiles.
  • This is another area that having a common understanding helps.
  • The latest LRI guide release 2 is a pretty good example, probably gets more complex than Death Reporting. Do not recommend the edos one.