This wiki has undergone a migration to Confluence found Here
20130815 TSC Content Review Team Call
Jump to navigation
Jump to search
| Content Review Team Agenda/Minutes Location: call 770-657-9270 using code 985371# |
Date: 2013-08-15 Time: 3 pm Eastern Time | ||
| Facilitator | Austin Kreisler | Note taker(s) | Lynn |
| Attendees | |||
| |||
| no quorum definition | |||
Agenda
Agenda Continue content review at http://wiki.hl7.org/index.php?title=Health_eDecisions
Minutes
- KenK reports
- Constrained version of R2 datatypes now being used
- Documentation of what the vMR is and intends to do has been added.
- DAM as logical data model discussed
- data model intended to be implementable for rules engines
- I/O using internal data format is one use. Others take in different types of documents e.g. CCD and convert to vMR data model.
- Jean asks if the Knowledge artifact and DSS IG are a set of services? Aziz states the Knowldege Artifact ID specifies artifacts consumed by CDS systems, and data elements are specified for structuring those inputs and outputs. KenK notes it's similar in approach to Arden Syntax or GELLO where artifacts are incorporated into the specification. Bryn notes the artifacts encode the CDS knowledge so that it can be shared in a consumable way.
- KenK reviews the HL7 vMR DAM information and executive summary.
- Jean finds it difficult to relate this to existing artifacts and asks why they have come to HL7 to ballot it, (as he asks of RCRIM from time to time). KenK notes they wished to define semantics like HL7, and driving from HL7 specs. Stakeholders and SMEs also congregate around HL7.
- Paul and Jean remark on the problematic nomenclature of IGs when the material contains a specification.
- Use case 1 is to programmatically share CDS. It stays away from what a service offering CDS looks like.
- Lorraine asks about structures defining input and output that wrap around the content which are different wrappers from what HL7 typically uses.
- Paul notes that while simplification is great, value to the community is of more importance. If the community is singular in terms of requirements then the simplification is readily consumed. However if the community has to deal with both the original "thing" and the "simplified thing" it does not make their job easier.
- Definition of knowledge engineer discussed: Limited healthcare background or technical background like business analysts and use rules engines in an EMR to write rules received through requirements from clinicians.
- Paul asks if the content is truly informative or normative. Is it something that would conventionally be packaged into one document or several, and there may be a temporal perspective that we'll ballot as draft and get to the division of the material later. Austin notes that as a DAM when originally titled its informative status was implied. However informative documents can be on an informative track. Jean notes that he understands it better as as an abstract data model that has an implementation database, and allows the CDS services to be standardized.
- Exclusion of null flavors discussed at length.
- Time being constrained - scheduling for next week's calls discussed.
- Tuesday 3 pm for a few more weeks. Austin not available next Thursday.
- Overview continues on ITS.
Meeting Outcomes
| Actions
|
Next Meeting/Preliminary Agenda Items
|
© 2013 Health Level Seven® International. All rights reserved
