MFI 4 Extended Registry SC32/WG2

Transcription

1 ISO/IEC MFI 4 Extended Registry Masaharu Obayashi SC32/WG

2 The relationship between Part 4 and the other parts (1) Specialization approach The metamodels of MFI 3,5,6,7,8,9,,,, are specialization of MFI 2 For each part, metamodel registries are specialized and maintained independently. Are other metamodels from a SDO, in the same way handled in this approach? MFI 4 is extension of MFI 2. (2) Encapsulation approach The metamodels of MFI 3,5,6,7,8,9 are independent metamodel and registered as component in MFI 4 registry where appropriate For each part, metamodel registries are specialized and maintained independently or can be implemented with common MFI 4 registry Other metamodels from a SDO, can be managed in the same way. MFI 4 is extension of MFI 2.

3 (1) Specialization approach class MFI-Core-other MDR-3 Context Administerd Item MFI-core Language Model 1..* +consistsof 0..* Model Component MFI-3,4,5,6,7,8 Whole Model Sub Component-1 Sub Component-x

4 (2) Encapsulation approach class MFI-Core-other MDR-3 Context Administerd Item MFI-core Language Model 1..* +consistsof 0..* Model Component Process Model MFI-4 Package Whole Model Model Sign MFI-4 Model Domain Model Concept Model Connector registering Process Instance Model Selection Model Instances

5 MFI Part4 : Extended Registry pkg Model Selection Model Specification - conformance level: string[0..*] - format: string[1..1] - issue date: data[1..1] - normativereference: string[0..*] - original: URI[1..1] - purpose: string[1..1] - scope: string[1..1] - source: string[1..1] - status: string[1..1] - termdefinitions: string[0..*] - title: string[1..1] - version: numeber[1..1] MDR-ByMOF::Adminstered Item +specifies 0..* ModelClassifier +specified by ModelDomainProfile - conformance: string[0..*] - domain name: string[1..1] ModelSign +designated +designates by ModelConcept +classified by fi es + classifier name: string[1..1] binding constratint 2 + modeltype: typecode[1..1] + namespace: string[1..1] 1] 0.. * * 1 + usagetype: typecode[1..1] 1] + sign: string[1..1] + attachementype: string[0..1] + attachement: URI[0..1] +labeled by xml: text binding constratint2 +has as construct 0..* +as upper model 0..* 1 1 +sourceupper +conceputalaized by MFI-Core::Component binding constraint3 - component type: typecode - name: string[1..1] Model Connector - conformance: string[0..*] binding constratint1 +as lower model +conceptualizes 0..* targetlower +labels 0..* 0..* ModelSelection +selected by+selects ModelInstance grouped by - condition: string[1..1] 0..* 1 - conceputalization ti type: typecode[1..1] 1] 0..* ModelComponentSet 1 +linked by - component type: typecode[1..1] - format: string[1..1] 0..* +targetupper 1 LevelPair Rule - definitiontype: typecode - lowerruletype: typecode - name: string - ruledefinitionuri: URI - upperruletype: typecode sourcelower 1..* Transformation +levelpairrule - name: string - transformationtype: typecode

6 Informal description of MFI extended registry model ModelComponent is unit of registered elements. Actually there are various granularities and abstraction levels. ModelComponentSet is aggregation of ModelComponent. The instance of ModelComponentSet is derived one from power set of ModelComponent. The instance of ModelComponentSet is the classified grouping elements of ModelComponent. ModelInstance is a role to conceptualize the grouped ModelComponentSet by upper defined ModelConcept. ModelInstance is aggregation again of ModelComponentSet. It seems double packaging of ModelComponent. It intents that ModelComponentSet of ModelInstance is able to be chosen for alternative ModelComponentSet elements. For example, it can be versioning of ModelComponentSet, new one will be added the ModelInstances that has old version of ModelComponent Set. Above all (ModelComponent, ModelComponent Set, ModelInstances) should be registered as common use as possible. The other hand, ModelConcept is designated with ModelSign for human communication. (ModelConcept can exist without any ModelSign). ModelSign is to designate ModelConcept, it is possible to put many ModelSigns to the same ModelConcept as synonym. For example, different terms are used for the same concept if the domains are different. Finally, ModelSelection, it is a very important notion in the MFI core model. ModelInstance consists of ModelComponentSet as mentioned above. The ModelInstances is specified (conceptualized) with upper ModelConcept. However, it has no sign (term) to point it for human communication. ModelSelection is a role of labeling the interesting ModelInstance with registered ModelSign. And, it is able to select the ModelComponentSet in ModelInstances by the selection condition. In sum, ModelSelection is grouping the registered ModelComponents and labeling it with the sign, It includes the intentions such as what ModelSign should be used, which ModelInstances should be adopted, which ModelComponentSet in ModelInstances should be selected. In fact, a ModelComponentSet has different ModelSign via different ModelInstance. From the other side, a ModelSign can be used to stand for the different ModelComponents. ModelSelection, l for example, is a role to specify the standard dmodelcomponentset t such as adopted dby each region, business field, group, company. ModelComponent is able to have sub ModelComponent via ModelSelection. It means that ModelComponent is not directly connected to another ModelComponent. Concrete actual use ModelComponent can be decided from selected ModelInstances, which has the same function (concept), according to the selection condition. In this way, managing and registering i information such as framework is able to search the information from various viewpointsaccording i to many purposes. In the example of RoR, the Registry type on display is handled in ModelSign internally in the MFI registry. Comparing selected ModelComponentSet for each business filed and analyzing labeled ModelSign, we can find the proper difference of Concept and understand the ontology in the true sense of the term.

7 domain classifier MFI 4 Extended Registry M3 sign instances domain Component Set sign instances classifier M2 M1 Component Set component M0

8 ISO/IEC MFI 4 Et Extended ddregistry Example of Registry Target: HITSP Harmonization Framework Masaharu Obayashi SC32/WG

9 HITSP Harmonization Framework IS = Interoperability Specification Addressing Business Needs Defining Information Content IS Capability Service Collaboration Transaction, Transaction Package Components Data Architecture Available for Independent Implementation Providing Infrastructure, Security, Privacy

10 HITSP class Data Data Architecture Architecture within HITSP Harmonization Framework EHR System Interoperability Specifications HITSP Documents are available at Detailed HITSP Data Architecture is available online at ARRA Requirement for Certified EHR Systems Scenario + conditions ARRA Meaningful Use Measures + Stakeholder EHR system Interoperability Specification Legend Data Requirement (DR) + Data Module Information Exchange Requirement (IER) + Systems + Exchange Content + Exchange Action + Exchange Attribute Regulatory Guidance Certification Criteria + Capability requirements design GREEN indicates reusable elements HITSP Constructs Capability Capability Design + conditions + optionality + system role Capability Requirements + Information Exchange + option + Scenario + system role Data Architecture Data Architecture HITSP/TN901 - Technical Note for Clinical Documents Component (C) Service Collaboration (SC) Data Module HITSP/C83 - CDA Content Modules Component Transaction (T) Data Element HITSP/C154 - HITSP Data Dictionary Transaction Package (TP) HITSP Constructs HITSP/TN904 - Harmonization Framework and Exchange Architecture Technical Note Selected Standard Value Set HITSP/ C80 - Clinical Document and Message Terminology Component HITSP/TN903 - Data Architecture Technical Note

11 sign instances HITSP class Data Data Architecture Architecture within HITSP Harmonization Framework Legend requirements design GREEN indicates reusable elements HITSP Constructs HITSP Constructs domain classifier Component Set EHR System Interoperability Specifications Component (C) Data Requirement (DR) + Data Module Transaction (T) Transaction Package (TP) Capability Capability Design + conditions + optionality + system role HITSP/TN904 - Harmonization Framework and Exchange Architecture Technical Note Service Collaboration (SC) MFI 4 Extended Registry component sign instances domain classifier M3 M2 M1 Component Set HITSP Documents are available at Detailed HITSP Data Architecture is available online at ARRA Requirement for Certified EHR Systems Scenario + conditions Information Exchange Requirement (IER) + Systems + Exchange Content + Exchange Action + Exchange Attribute Capability Requirements + Information Exchange + option + Scenario + system role Data Architecture Selected Standard Regulatory Guidance Data Module Data Element Value Set ARRA Meaningful Use Measures + Stakeholder Certification Criteria + Capability EHR system Interoperability Specification Data Architecture HITSP/TN901 - Technical Note for Clinical Documents HITSP/C83 - CDA Content Modules Component HITSP/C154 - HITSP Data Dictionary HITSP/ C80 - Clinical Document and Message Terminology Component HITSP/TN903 - Data Architecture Technical Note M0 Interoperability Specification, Service Collaboration, Transaction Package, Transaction, Component, Technical Note, Reference Documents Interoperability Specification Back To Top IS01 Electronic Health Records Lab Results Reporting IS02 Biosurveillance IS03 Consumer Empowerment and Access to Clinical Info via Networks IS04 Emergency Responder EHR IS05 Consumer Empowerment and Access to Clinical Information via Media IS06 Quality IS07 Medication Management IS08 Personalized Healthcare IS09 Consultations and Transfers of Care IS10 Immunizations and Response Management IS107 EHR Centric Interoperability Specification IS11 Public Health Case Reporting IS12 Patient Provider Secure Messaging IS77 Remote Monitoring Service Collaboration SC108 Access Control SC109 Security Audit Back To Top SC110 Patient Identification Management SC111 Knowledge And Vocabulary SC112 Healthcare Document Management SC113 Query for Existing Data SC114 Administrative Transport to Health Plan SC115 HL7 Messaging SC116 Emergency Message Distribution Transaction Package Back To Top TP13 Manage Sharing of Documents TP20 Access Control TP21 Query for Existing Data TP22 Patient ID Cross Referencing TP30 Manage Consent Directives TP43 Medication Orders TP46 Medication Formulary and Benefits Information TP49 Sharing Radiology Results TP50 Retrieve Form for Data Capture TP89 Sharing Imaging Results Transaction Back To Top T14 Send Lab Result Message T15 Collect and Communicate Security Audit Trail T16 Consistent Time T17 Secured Communication Channel T18 View Lab Results From Web App T23 Patient Demographics Query T24 Pseudonymize T29 Notification of Document Availability T31 Document Reliable Interchange T33 Transfer of Documents on Media T40 Patient Health Plan Eligibility Verification T42 Medication Dispensing Status T63 Emergency MessageDistribution Element T64 Identify Communication Recipients T66 Retrieve Value Set T67 Clinical Referral Request Transport T68 Patient Health Plan Authorization Request and Response T79 Pharmacy to Health Plan Authorization Request and Response T81 Retrieval of Medical Knowledge T85 Administrative Transport to Health Plan Component Back To Top C19 Entity Identity Assertion C25 Anonymize C26 Nonrepudiation of Origin C28 Emergency Care Summary Document C32 Summary Documents Using CCD C35 Lab Result Terminology C36 Lab Result Message C37 Lab Report Document C38 Patient Level Quality Data Document C39 Encounter Message C41 Radiology Result Message C44 Secure Web Connection C47 Resource Utilization C48 Encounter Document C62 Unstructured Document C70 Immunization Query and Response C72 Immunization Message C74 Remote Monitoring Observation Document C75 Healthcare Associated Infection Report C76 Case Report Pre Populate C78 Immunization Document C80 Clinical Document and Message Terminology C82 Emergency Common Alerting Protocol C83 CDA Content Modules C84 Consult and History and Physical Note C87 Anonymize Public Health Case Reporting Data C88 Anonymize Immunizations and Response Management Data C90 Clinical Genomic Decision Support Technical Note Back To Top TN900 Security and Privacy TN901 Clinical Documents TN903 Data Architecture TN904 Harmonization Framework Reference Documents Back To Top REF12 Quality Measure Reference Document REF4 HITSP Acronyms List REF6 HITSP Glossary TP13 Manage Sharing of Documents Table of Contents 1.0 INTRODUCTION Overview Copyright Permissions Reference Documents Conformance C Conformance Criteria. Cit i Conformance Scoping, Subsetting and Options Intra Community Sharing of Documents (XDS.a Option) Intra Community Sharing of Documents (XDS.b Option) Cross Community Sharing of Documents (XCA Option) Transaction Package Definition Context Overview Interfaces Interface Interactions Cross Enterprise Document Sharing XDS.a Option Cross Enterprise Document Sharing XDS.b Document Integrity Option XCA Cross Community Access Gaps Terminology Cross Affinity Domain Document Sharing Pre conditions Process Triggers Post conditions Required Outputs Data Flows List of HITSP Constructs. 22 Model Selection Construct Dependencies Additional Constraints on Required Constructs Standards Regulatory Guidance Selected Standards Informative Reference Standards Appendix IHE Transactions Document Updates November 4.1 6, Version Compatibility: December 5, December 13, March 19, March 27, August 20, August 27, December 10, December 18, June 30, J 4.11 July 8, XDS systems

12 ISO/IEC MFI 4 Et Extended ddregistry Example of Registry Target: MFI 5 Process Model Masaharu Obayashi SC32/WG

13 MFI 5: The metamodel for process model registration

14 Relationship between MFI PMR and some parts in MFI

15 Examples of MFI PMR registration

16 domain classifier MFI 4 Extended Registry M3 BravoAir_Process Examples of MFI PMR registration sign instances domain Component Set sign classifier M2 instances M1 Component Set component M0 Actor, Goal, Process, Goal, Service, Resource MFI 5: The metamodel for process model registration BravoAir systems