2017-01-24 1 views
3

사용자 지정 확장 프로그램을 Schedule 리소스에 추가하려면이 파일을 추가하고 싶습니다. 내 앱에서 일정에 방문 동기 (이유)가 있습니다. 나는 분류 된 약속/만남의 이유가 있음을 알고 있지만 내 것을 사용하고 싶습니다.FHIR : 사용자 지정 확장 추가

나는 이런 식으로 뭔가가 :

{ 
    "resourceType":"Schedule", 
    "identifier":"logical_id", 
    "type":"schedule_speciality", 
    "actor":{ 
    "practioner_id":"identifier", 
    "practioner_name":"practioner name" 
    }, 
    "external_id":{ 
    "extension":[ 
     { 
     "url":"http://api.test.com/fhir/schedule/external_id", 
     "valueIdentifier":"external_id" 
     } 
    ] 
    }, 
    "visit_motives":{ 
    "extension":[ 
     { 
     "url":"https://api.test.com/fhir/ValueSet/schedule#visit_motives", 
     "valueString":"vist_motive1" 
     }, 
     { 
     "url":"https://api.test.com/fhir/ValueSet/schedule#visit_motives", 
     "valueString":"vist_motive2" 
     }, 
     { 
     "url":"https://api.test.com/fhir/ValueSet/schedule#visit_motives", 
     "valueString":"vist_motive3" 
     } 
    ] 
    }, 
    "practice_id":{ 
    "extension":[ 
     { 
     "url":"https://api.test.com/fhir/schedule/practice_id", 
     "valueIdentifier":"practice_id" 
     } 
    ] 
    } 
} 

잘 모르겠어요이 부분에 대한 :

"visit_motives":{ 
    "extension":[ 
     { 
     "url":"https://api.test.com/fhir/ValueSet/schedule#visit_motives", 
     "valueString":"vist_motive1" 
     }, 
     { 
     "url":"https://api.test.com/fhir/ValueSet/schedule#visit_motives", 
     "valueString":"vist_motive2" 
     }, 
     { 
     "url":"https://api.test.com/fhir/ValueSet/schedule#visit_motives", 
     "valueString":"vist_motive3" 
     } 
    ] 
    } 

는 확장이 방법을 추가 정확을? 특정 스케줄에 대해 항상 여러 방문 동기가 있으므로 나열해야합니다.

"visit_motives": { 
      "coding": [ 
      { 
       "system": "https://api.test.com/fhir/ValueSet/schedule#visit_motives", 
       "code": "visit_motive1" 
      } 
      ] 
     } 

한 올바른 하나는 내가 잘못되어

은 또한 사물의 종류를 보았는가?

답변

3

여기에 몇 가지 문제가 있습니다 : 일정에 "이유를"캡처 이상한 것 같다

  1. . 일정은 특정 임상 의나 클리닉 또는 기타 리소스를 사용할 수 있다고 말합니다. 예 : "스미스 박사는 월 ~ 수/금 오후 1 시부 터 4 시까 지 약속을 잡습니다." 따라서 자원에 대한 이유를 파악하려면 "왜 스미스 박사가 일정을 잡았습니까?"라고 나타낼 것입니다. 일반적으로 개별 약속에 대한 이유가 캡처됩니다. 그것이 계획된 방문을위한 특정 슬롯을 예약하는 리소스입니다. 그리고 Appointment에는 자신의 코드를 자유롭게 사용하거나 텍스트를 보낼 수있는 이유가 있습니다.

  2. 식별자를 전달하는 확장 프로그램이 있지만 일정에는 이미 식별자 용 요소가 있습니다. 표준 요소 대신 확장을 사용하는 이유는 무엇입니까? "시스템"및/또는 "유형"구성 요소를 사용하여 여러 종류의 식별자를 구별 할 수 있습니다.

  3. 당신은 "식별자", "유형", "이름", 등의 간단한 문자열을 보내는 -하지만 당신은

  4. 배우가 자식 요소를 통신 할 필요가 그들이 그렇게 복잡한 데이터 유형이야 참조 유형 - 그것은 당신이 Practitioner 리소스를 가리킬 필요가 있다는 것을 의미합니다. 속성을 인라인으로 보낼 수 없습니다. (실무자가 일정의 맥락에서만 존재하는 경우 내부 참조를 사용하는 "포함 된"접근법을 사용할 수 있지만 포함은이 유스 케이스에서는 이해가되지 않는 것처럼 보입니다

  5. URL 확장이 모든 구조 정의입니다. 또한 URL에 # 기호가 없어야합니다.

  6. 확장을위한 구문이 올바르지 않습니다. FHIR의 속성. 모든 확장 기능의 속성 이름은 "확장자"이며 URL로 구분되므로 구문은 다음과 같아야합니다.

{ 
    "resourceType":"Schedule", 
    "id":"logical_id", 
    "extension": [ 
    { 
     "url":"https://api.test.com/fhir/StructureDefinition/schedule-visit_motive", 
     "valueString":"vist_motive1" 
    }, 
    { 
     "url":"https://api.test.com/fhir/StructureDefinition/schedule-visit_motive", 
     "valueString":"vist_motive2" 
    }, 
    { 
     "url":"https://api.test.com/fhir/StructureDefinition/schedule-visit_motives, 
     "valueString":"vist_motive3" 
    } 
    ], 
    "identifier": [ 
    { 
     "system": http://api.test.com/fhir/NamingSystem/external_id", 
     "value": "external_id" 
    } 
    { 
     "system": http://api.test.com/fhir/NamingSystem/practice_id", 
     "value": "practice_id" 
    } 
    ] 
    "type": { 
    "coding": { 
     "system": "http://somewhere.org/fhir/CodeSystem/specialties", 
     "code": "schedule_speciality" 
    }, 
    "text": "Some text description of specialty" 
    }, 
    "actor":{ 
    "reference": "http://myserver.org/fhir/Practitioner/12345" 
    "display": "Dr. smith" 
    } 
} 
+0

우선 자세한 답변을 부탁드립니다! 1. 이유는 내 앱의 일정과 관련이 있습니다. 일정은 이유 목록에없는 약속을 가질 수 없으며 어떤 API가 일정을 지원하는지 알기 위해 내 API를 사용하는 사람들이 필요합니다. 2. 알았어. 3. 나의 실수, 나는 그것을 지금 이해한다. 4. 알았어? 5. 알았다. 6.완벽한, 그게 내가 여기 온 이유지만, 방금 더 많은 정보를 제공해 줬어, 정말 고마워! – user2462805

+0

슬롯 레벨에서 이유를 포착하는 것을 고려해 볼 수 있습니다. 이는 예약 할 수있는 약속 종류에 제약 조건을 두는 것보다 일반적입니다. 그러나 일정 수준에서 실제로 필요한 경우에는 확장 기능을 올바르게 사용하고 있습니다.이 기능을 통해 비정형 요구 사항을 지원할 수 있습니다. –

+0

여기의 유스 케이스는 제공자 블록이라고 생각합니다. 예를 들어 스미스 박사는 8-10 세의 "건강한 어린이 방문", 12-5 세의 기존 환자 방문을 받아 들일 수 있습니다. 그는 12-2에서 새로운 환자 방문을 허용 할 수도 있습니다 (12-2는 신규 또는 기존 중 하나 일 수 있음). 만약 당신이 특정 서비스 제공자의 슬롯이 지원할 수있는 서비스를 가리킬 수 있도록 HealthcareService에 대한 참조를 매달아 놓는 것이 합리적인지 궁금합니다. (Schedule과 배우의 HealthcareService 링크는 모두 1..1이고 isn 어느 한쪽 또는 시나리오에 충분하다). – Cooper

관련 문제